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The  success  or  failure  of  weapons  systems  software 
projects  can  often  be  traced  back  to  the  project's 
definition  phase.  There  currently  exists  in  the  literature 
ran y  articles  dealing  with  the  prc biers  inherent  in  the 
development  of  requirements  specifications.  This  thesis 
reviews  sore  of  the  problems  a^d  examines  an  evolving, 
disciplined  method  to  better  state  the  users'  requirements, 
called  Requirement  Statement  Languages  (RSL).  Two  autoratei 
systems  utilizing  RSI,  SRJM  and  PSL/PSA.  are  reviewed  as  t.o 
their  strengths  and  weaknesses  ir  system  definition  end 
development,  particularly  as  they  are  currently  used  in  the 
Navy.  Also  discussed  are  hew  these  systems  ray  be  utilized 
in  the  Navy's  system  acquisition  process  and  ne^enrendat ion s 
are  made  as  to  how  the  Navy  can  incorporate  sunn  software 
technology . 
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I.  INTRODUCTION 


The  Department  of  Defense  is  faced  every  year  with  the 
development  of  clear,  concise  requirements  specifications 
for  hundreds  of  systems.  These  specifications  serve  as  a 
vehicle  for  the  development  of  systems  that  are  vital  to  the 
support  of  the  missions  of  the  armed  services  end,  more 
importantly,  the  overall  national  defense.  It  is  with  these 
specifications  that  the  relative  success  or  failure  of  the 
development  of  a  system  rests. 

For  example,  take  a  real-time  combat  system.  The  first 
feature  of  such  a  system  is  that  it  is  required  to  he  highly 
reliable  >  ideally  it  should  function  properly  at  all  times. 
This  system  is  required  to  be  extremely  flexible  in 
response.  Conditions,  be  they  meteorological, 
electromagnetic,  tactical,  etc.,  can  vary  rapidly  thus 
forcing  the  development  of  a  system  that  is  almost 
self-adjusting.  Automation  is  a  prerequisite  for  such  a 
system  due  to  the  short  length  of  engagements  forseen  in 
future  military  encounters  and  because  the  programs  that 
drive  such  systems  are  large  and  quite  complex,  receiving 
many  Inputs  and  then  performing  multiple  commmand  and 
control  functions.  [1]  [2] 

Unfortunately,  the  above  requirements  cannot  be 
adequately  tested  in  anything  other  than  either  an 
operational  evironment  [ll  or  a  highly  realistic  simulation. 
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making  development  of  precise  requirements  specifications 
even  more  critical. 

Much  to  the  consternation  of  the  project  offices  and 
end-users,  many  problems  exist  in  the  area  of  requirements 
specifications.  These  problems  cost  the  taxpayers  millions 
of  dollars  and  create  countless  headaches  for  the  military 
as  it  is  delivered  systems  that  do  not  perform  as  expected. 

Vhat  are  some  of  the  causes?  Part  of  it  is  due  to  the 
fact  that  some  of  the  projects  are  simply  too  ambitious.  All 
of  the  requirements  that  are  forced  on  a  system  raise  the 
level  of  complexity  to  the  point  where  the  project  is 
absolutely  infeasible  in  terms  of  technology,  time,  and 
money.  On  a  higher  level,  too  often  ambiguous,  incomplete, 
and  untestable  requirements,  symptoms  of  poor  communication , 
are  forced  upon  contractors,  often  coupled  with  documentary 
information  that  is  factually  incorrect.  [3] 

Once  the  requirements  specifications  reach  the 
contractor  there  immediately  is  the  livelihood  of 
misinterpretation  due  to  the  aforementioned  ambiguity  and 
incompleteness,  plus  the  fact  that  many  of  the  requirements 
are  highly  conceptual  in  nature.  The  programmer  who  views 
structured  design  as  a  handicap  and  is  more  concerned  with 
code  than  with  overall  design  further  exacerbates  the 
problem  [2] . 

Between  the  initial  misinterpretation  and  the 
programmer's  code  comes  the  problem  with  the  design  phase. 
Too  often  there  seems  to  be  subsystem  optimization  at  the 


expense  of  the  overall  system.  [2]  This  is  the  result  of  the 
pressures  of  time  and  "pride  of  workmanship"  rather  than  an 

attempt  to  undermine.  Development  and  maintenance  of 
structure  charts  are  another  problem.  [2]  Typical  charts 
measure  20'  by  10'  and  take  days  to  update.  Finally, 
inconsistent  and  ill  defined  approaches  in  this  phase  have 
resulted  not  only  in  lackluster  results,  but  also  in  poor 
presentation,  inconsistency,  incompleteness,  and  general 
confusion  about  the  status  of  the  project  in  question.  [3] 

Hammond  et  al.  [4]  noted  the  importance  of  careful 
design;  that  errors  originating  during  the  design  phase  are 
very  costly  to  correct  during  later  development.  They  cited 
a  DOD  report  that  estimated  that  design  errors  discovered 
during  the  operation  of  a  system  cost  8-9  times  more  to 
correct  than  those  detected  during  the  detailed  design. 
Munson  [5]  cited  another  DOD  report  that  stated  that 
approximately  60-70%  of  its  software  dollars  ($2  billion  in 
1976)  are  spent  after  software  has  beer,  tested  and 
delivered . 

It  is  the  intent  of  this  thesis  to  look  at  the  problem 
of  requirements  specifications  in  terms  of  what  they  are, 
how  they  should  be  properly  utilized,  and  how  their 
effectiveness  can  be  enhanced  when  developed  through  the 
relatively  new  concepts  of  requirement  statement  languages 
and  software  requirements  methodologies.  Two  of  the  more 
mature  systems  utilizing  this  concept,  the  Software 
Requirements  Engineering  Methodology  and  the  Problem 
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Statement  Language/Problem  Statement  Analyzer,  will  be 
reviewed  as  to  their  capabilities  and  possible  limitations 
in  development  of  requirements  specifications  ir.  DOD .  This 
thesis  will  also  examine  how  these  systems  may  be  utilized 
in  the  Navj's  system  acquisition  process  and  will  make 
recommendations  as  to  how  the  Navy  can  incorporate  such 
software  technology. 


II.  BACKGROUND 


tfullery  [4],  Balzer  and  Goldman  [6],  and  Heninger  [7] 
have  all  addressed  the  question  of  exactly  what  the  overall 
alms  of  requirements  specifications  should  be  and  how  these 
aims  can  be  realized. 

The  most  basic  aim  of  a  requirement  specif lcat Ion  should 
be  that  of  defining  the  requirement  so  that  the  system  may 
be  Implemented  later  and  be  proven  to  have  been  Implemented 
correctly  and  also  to  define  the  requirement  so  that  the 
customer  and  end-user  can  verify  that  the  system  will 
perform  the  requisite  functions.  f4]  This  forces  the  issue 
of  clarity  and  the  elimination  of  amblculty.  Forethought, 
systematic  development  of  specifications,  and  error  checking 
of  system  logic  on  a  very  high  level  are  paramount. 

The  requirement  specification  should  take  a  modular 
approach  to  the  task  of  system  definition.  The  specification 
must  be  localized  and  loosely  coupled  [6]  and  should  specify 
external  behavior  only  so  as  not  to  force  a  particular 
solution  [7],  Since  during  system  development  many 
modifications  are  likely,  the  separation  of  particular 
requirements  (localizing  and  loosely  coupling)  contributes 
greatly  to  the  overall  flexibility  of  the  system  development 
and  minimizes  the  side  effects  of  modifications.  To  carry 
this  thought  even  further,  the  specifications  must  be 
tolerant  of  any  omissions  and  permit  augmentation  of 
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requirements  at  some  future  point  [6]  T?] .  This  would  seem 
to  defeat  the  purpose  of  structured  formulation  of 
requirements  specifications  but  it  is  necessary  due  to  the 
highly  iterative  nature  of  large  system  design  and  the 
uncertainties  of  the  human  thought  process. 

As  a  design  tool,  these  specif ications  should  be 
consistent  and  compatible  for  each  of  the  individual 
requirements  [3].  Such  things  as  naming  conventions  for  the 
various  components  and  interfaces  between  modules  must  be 
considered.  Also,  avoidance  of  unnecessary  repetition  of 
information  so  as  to  reduce  bulk  and  prevent  possible 
confusion  is  important. 

Three  other  key  aids  to  design  are  (1)  to  define  each 
module  so  that  all  parties  involved  in  the  design  of  the 
system  can  grasp  the  overall  concept  of  the  system  T5] ,  (2) 
to  characterize  acceptable  responses  to  undesired  events, 
and  (3)  specify  constraints,  particularly  in  the  area  of 
hardware  interfaces  [7] .  All  of  these  serve  as  a  means  of 
defining  the  overall  system  and  its  purpose. 

Heninger  went  even  further  by  stating  that  the 
specifications  should  serve  as  a  reference  tool,  having  the 
ability  to  answer  specific  questions  quickly,  and  also 
record  forethought  about  system  lifecycle  costs.  What  types 
of  changes  are  likely  to  occur?  What  functions  would 
maintenance  like  to  be  able  to  remove  easily?  [7] 

Merten  and  Teichrow  [8]  cited  a  study  by  the  Office  of 
Management  and  the  Budget.  The  study,  conducted  to  improve 


the  effectiveness  of  systems  analysts  and  programmers, 
stated  that  the  most  important  way  to  improve  the 
effectiveness  of  these  personnel  is  to  reduce  the  time  spent 
on  and  greatly  improve  the  efficiency  of  systems  analysis, 
design,  implemetations ,  and  maintenance.  Granted,  this 
statement  in  and  of  itself  says  nothing  new,  but  it  does 
reinforce  the  idea  of  a  need  for  a  more  rigorous, 
disciplined  approach  to  systems  design  and  implementation. 
This  approach  to  be  successful  and  effective  must  start  with 
the  requirements  specifications. 

Willis  and  Jensen  [2l  noted  the  shortcomings  of 
so-called  "methodologies"  vis  a  vis  engineering  when  they 
described  methodologies  as  being  generic  and  subject  to 
interpretation.  Conversely,  they  cited  engineering  as  a 
discipline  that  stresses  standardization  and  serves  as  a 
much  more  effective  and  efficient  vehicle  for  developing 
systems  and  conveying  information  and  concepts.  They  went 
even  further  by  explaining  that  the  fundamental  precepts  of 
systems  engineering  must  be  preciseness,  consistency,  and 
completeness  of  applications.  They  also  felt  the  use  of 
automated  tools  to  be  necessary  for  training,  configuration 
control,  and  quality  control. 

Since  computers  are  used  for  design,  modeling,  and 
simulation  in  other  areas,  why  not  use  them  to  generate 
requirements  and  overall  system  design? 
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III.  REQUIREMENTS  STATEMENT  LANGUAGE 

On  a  macro  level,  the  use  of  engineering  principles  and 
automated  tools  looks  like  a  boon  to  mankind.  However, 
whether  one  communicates  with  a  computer  or  with  a  team  of 
designers,  the  fact  still  remains  that  a  medium  is  still 
necessary  to  effectively  convey  system  requirements.  For 
years  proponents  of  natural  languages  such  as  English  have 
claimed  far  and  wide  that  these  languages  are  "very  high" 
level  and  that  their  use  constitutes  the  wave  of  the  future. 
Exception  to  this  is  taken  by  Jones  [9].  His  own  Independent 
survey  noted  that  English  is  actually  a  very  low  level 
language  as  it  requires  3  to  11  times  as  many  English  wcrds 
to  specify  a  program  as  it  takes  lines  of  assembler  to  code 
it.  He  found  that  with  programs  that  exceed  128K  lines  of 
assembler  specifications  become  too  bulky  and  cease  to  be 
useful.  It  is  at  this  point  that  "verbal  communication" 
becomes  the  dominating  factor. 

Combining  the  findings  of  Jones  with  one's  own 
experience  with  the  vagueness  and  ambiguity  inherent  in  the 
use  of  the  English  language,  it  becomes  readily  apparent 
that  what  is  required  Is  a  requirements  statement  language, 
a  language  that  precisely,  concisely,  and  completely  conveys 
to  all  concerned  the  actual  user  requirements. 

Whereas  a  programming  language  serves  as  a  means  of 
communication  between  a  programmer  and  a  compiler  or 
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assembler,  a  requirements  statement  languaee  (RSL'  should 
serve  as  a  means  of  ccmmunlca tion  between  the  user  and  an 

analyst  or  system  designer  [a].  Teichrow  [10]  listed  three 
main  functions  of  an  RSL: 

1.  RSL  should  accomodate  the  statement  of  requirements 
of  the  kind  that  are  occuring  new  as  well  as  those  in  the 
future . 

The  future  will  produce  hardware  improvements  in  both 
quality  and  reliability.  Parallel  processing  and  concurrency 
will  become  more  common.  There  will  be  a  marked  increase  in 
the  interrelationship  of  requirements.  As  the  number  and 
types  of  users  increase,  additional  problems  of  interfacing 
will  arise,  Par  greater  demands  for  system  performance  and 
real-time  applications  will  occur.  There  will  also  be  an 
additional  requirement  for  system  monitoring.  All  of  these 
problems  and  more  must  be  taken  into  consideration  in  the 
design  of  an  RSL. 

2.  RSL  should  be  suitable  for  use  by  humans  for 
determining  and  stating  requirements. 

The  RSL  should  be  so  structured  that  it  can  be  used  by 
personnel  on  all  levels,  in  all  phases  of  design.  This 
hopefully  will  reduce  the  strict  dependency  on  the  analyst 
as  a  go-between  for  management  and  design.  The  RSL  should 
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also  be  suitable  for  use  in  top-down  design  and  should  be 
computer  testable  for  completeness  and  consistency.  All  of 
this  should  augment  the  capabilities  of  those  involved  in 
the  defintiion  of  requirements. 

3.  RSL  should  be  suitable  for  building  the  system  to 
accomplish  the  stated  requirements. 

This  will  occur  if  the  RSL  is  allowed  to  generate 
statements  of  requirements  and  not  statements  of  data 
processing  —  what  the  system  is  supposed  to  do,  not  how  to 
do  it.  This  will  aid  in  keeping  the  requirements  hardware 
independent,  thus  saving  possible  reconversion  costs. 

Merten  and  Teichrow  [8l  amplified  the  last  few 
statements  when  they  noted  that  the  major  purpose  of  the  RSL 
is  to  force  the  user  to  state  his  requirements  in  a  manner 
which  does  not  force  a  particular  processing  procedure. 
However,  they  also  noted  that  this  is  a  difficult  concept  to 
impose  given  the  techniques  that  are  ingrained  in  the 
specification  process.  If  followed  rigorously,  this  should 
reduce  the  existence  of  illogical  requirements  due  to  poor 
specifications. 

The  concept  of  RSL  is  not  new,  being  first  developed  as 
early  as  1958,  but,  until  recently,  has  not  been  in  wide  use 
due  to  the  lack  of  ability  to  analyze  problem  definitions  In 
the  RSL,  so  it  has  been  mainly  relegated  to  use  as  a 
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documentation  tool  [8].  Jones  [9]  noted  that  there  are  about 
150  design  languages  that  have  been  developed. 

The  following  chapter  will  address  a  current  methodology 
that  employs  a  requirements  statement  language,  namely  the 
Software  Requirements  Engineering  Methodology,  developed  by 
TRW  for  the  Ballistic  Missile  Tefense  system.  As  noted 
above,  there  are  some  150  languages;  however,  SREM  was 
chosen  for  further  discussion  due  to  its  relative  maturity 
of  development,  the  fact  that  it  was  developed  for  a  major 
project,  and  because  its  has  proven  successful  to  some 
degree.  Its  discussion  will  center  around  Its  structure  and 
Its  approach  to  system  specification  and  design. 


18 


IV 


SOFTWARE  REQUIREMENTS  ENGINEERING  METHODOLOGY 


A.  BACKGROUND 

In  1974  the  Ballistic  Mlsslle  Defense  Advanced 
Technology  Center  (RMDATC)  Initiated  sponsorship  of  an 
integrated  software  development  research  program  aimed  at 
improving  the  techniques  for  developing  correct,  reliable 
software  for  the  proposed  Ballistic  Missile  Defense  (PMD) 
system.  The  overall  program  sought  to  cover  a  broad 
spectrum,  from  development  of  software  specifications  tc  the 
completion  and  testing  of  the  software  process  design  [11] . 
Other  areas  of  research  involved  software  reliability, 
static  and  dynamic  validation  techniques,  and  adaptive 
control  and  learning. 

At  the  center  of  this  program  was  the  Software 
Requirements  Engineering  Program  (SREP),  an  effort  concerned 
with  a  systematic  approach  to  the  development  of  complete 
and  validated  software  requirements.  Its  overall  objectives 
were  to: 

1.  Ensure  a  well  defined  technique  for  the  decomposition 
of  system  requirements  into  structured  software 
requirements. 
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2.  Provide  a  vehicle  to  enable  management  to  clearly  see 
and  understand  all  phases  of  the  requirements  development. 

3.  Ensure  that  requirements  development  was  completely 
machine  and  design  independent. 

4.  Provide  for  easy  response  to  changes  in  systems 
requirements. 

5.  Produce  testable  and  easily  validated  software 
requirements  [11]  . 

The  product  of  the  above  program  is  the  Software 
Requirements  Engineering  methodology  (SREl“).  SREm  includes 
techniques  and  procedures  for  requirement  decomposition  and 
for  managing  the  requirements  development  process  [12]  . 
Within  this  methodology  are  software  support  tools  which 
were  implemented  to  automate  many  of  the  manual  activities 
associated  with  requirements  engineering.  Among  these  tools 
are  the  Requirements  Statement  Language  (RSL),  a 
machine-processable  language  for  stating  requirements,  and 
the  Requirements  Engineering  and  Validation  System  (REVS) 
which  supports  the  development  of  requirements  written  in 
RSL.  SREM  represents  a  different  approach  and  philosophy  for 
software  requirements  engineering.  It  utilizes  a  flow 
orientation  that  precludes  many  of  the  problems  Inherent  in 
the  classical  functional  hierarchy. 


The  functional  hierarchy  (Figure  1.)  is  the  most 
prevalent  way  to  organize  software  requirements.  In  Figure  1 
the  boxes  marked  B,C,  and  D  represent  major  functions  of 
software  such  as  tracking,  guidance,  etc.  These  major 
functions  are  broken  into  subfunctions  down  to  seven  to  ten 
levels.  It  is  from  these  lower  levels  that  the  requirements 
are  written. 

The  first  problem  encountered  with  this  approach  is  the 
requirements  are  written  at  too  low  a  level.  Though  each 
individual  subfunction  can  be  tested  for  correctness,  there 
is  extreme  difficulty  in  testing  the  system  as  a  whole,  i.e. 
top-down,  against  the  system  specification.  The  reouirements 
must  be  developed  so  that  each  condition  that  could  possibly 
be  encountered  can  be  traced  down  through  each  appropriate 
subfunction  until  the  output  is  determined. 

Another  problem  encountered  from  developing  requirements 
at  too  low  a  level  is  that  performance  requirements  are  not 
easily  derived.  This  is  due  to  the  fact  that  the  timeline 
and  accuracy  budgets  have  to  be  partitioned  among  too  many 
levels . 

Finally,  it  is  difficult  to  check  for  completeness  and 
consistency.  Since  there  is  no  algorithm  to  guide  the 
derivation  of  the  tree  structure,  there  is  no  algorithm  with 
provable  validity  to  guide  the  analysis. 

The  methodology  expressed  in  SBEM  encompasses  four  major 
areas  of  engineering  activity  that  commence  with  the  input 
of  Information  that  defines  the  system  level  requirements  on 


Figure  1 . 

Hierarchy  of  Functions 


the  Data  Processing  Subsystem.  This  information  is  denoted 
as  the  Data  Processing  System  Performance  Requirements 
(DPSPR)  Specification  [11].  The  DPSPR  includes  system 
interface  and  performance  requirements  specifications.  These 
enable  the  requirements  engineer  to  involve  himself  in: 

1.  identification,  definition,  and  development  of  the 
functional  requirements. 

2.  identification,  definition,  and  development  of  the 
performance  requirements. 

3.  development  of  the  Process  Performance  Requirements 
Specifications. 

4.  development  of  the  analytic  feasibility 
demonstrations . 

B.  SREM  OBJECTIVES 

The  key  concept  in  the  development  of  SREK  was  that 
design-free  functional  software  requirements  should  specify 
the  required  processing  in  terms  of  all  possible  responses 
(and  the  conditions  for  each  type  of  response)  to  each  input 
message  across  each  interface.  These  functional  requirements 
Identify  the  required  stimulus  and  response  which  are 
expressible  in  terms  of  Requirement  Networks  (R-Nets)  of 
processing  steps.  Each  step  is  defined  in  terms  of  input 
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data,  output  data,  and  the  transformations  which  are 
associated  with  the  step  fl3]  . 

Though  designed  for  the  BMD  system,  SBBH  was  aimed 
towards  any  major  system  with  the  following  characteristics: 


1.  Systems  with  more  than  100£  lines  of  code. 

2.  Tire  responses  are  critical.  This  is  the  criteria 
that  defines  a  "real-time"  system,  i.e.,  receiving  input, 
processing  the  information,  and  producing  output  that  will 
in  some  way  influence  the  immediate  environment. 

3.  Processing  is  very  intensive.  A  real-time  system 
could  perhaps  he  tasked  with  tracking  several  hundred 
targets . 


4.  Database  is  large  hut  not  massive.  The  database  must 
he  indigenous  to  the  system,  time  cannot  he  wasted  in 
information  retrieval, 

5.  Technology  of  the  object  system  initially  is  not 
fully  understood.  Justification  and  feasibility  of  the 
system  and  its  possible  subsystems  are  still  an  issue  [111. 

S BEK  was  also  designed  to  encompass  a  wide  range  of 
system  development  environments,  ranging  from  systems  which 
must  deal  with  hard  performance  requirements,  firm  threat 
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definition,  and  maximum  design  freedom,  to  systems  with 
minimum  performance  requirements,  flexible  threat 
definition,  and  reduced  design  freedom. 

SPEM  was  never  intended  to  be  the  ultimate  panacea  for 
the  woes  of  system  design  and  development.  A  thorough 
knowledge  of  systems  engineering  and  data  processing 
technology  are  still  paramount.  The  utilization  of  SBFM 
commences  only  after  system  analysis  has  identified  the 
functions  and  stress  points  of  the  system;  the  interfaces 
between  subsystems;  top-level  weapon  system  functions  and 
operating  rules;  and  the  top-level  weapon  system  functions 
have  been  allocated  to  the  data  processor. 

The  termination  point  is  reached  when  all  system 
requirements  have  been  decomposed  to  the  point  where 
software  development  expertise  is  necessary  to  continue; 
interfaces  have  been  defined  on  the  element  level;  all 
responses  to  system  stimuli  have  been  determined;  and  the 
processing  necessary  to  generate  all  required  output 
interface  messages  has  been  identified  [11]  . 

C.  SREK  EVOLUTION 

During  the  initial  definition  of  SREM  it  was  necessary 
to  determine  those  properties  required  of  both  a 
specification  and  of  the  individual  requirements  of  which  it 
is  composed.  The  initial  considerations  were  that,  first,  a 
specification  is  a  set  of  all  requirements  which  must  be 
satisfied  together  with  the  identification  of  the 
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which  rrust  be  met  concurrently.  Secondly,  a  specification 
rust  he  consistent  with  the  laws  of  logic  and  nature  before 

they  can  be  realizable  and  legally  birding.  Lastly,  a 
specification  must  be  so  stated  that  any  delivery  satisfies 
the  specification  and  the  user's  needs. 

The  above  considerations  were  further  evaluated  and 
rreshed  with  technical,  economic,  ard  management  points  of 
view,  producing  several  properties  that  were  felt  to  be 
mandatory  to  the  success  of  SREh!.  The  properties  that 
evolved  include: 

1.  internal  consistency 

2.  consistency  with  the  physical  universe 

3.  freedom  from  ambiguity 

4.  clarity 

5.  minimality 

6.  predictability  of  specification  development 

7.  controllability  of  software  development  fill. 

To  ensure  the  property  of  freedom  from  ambiguity,  it.  was 
mandatory  that  a  rigorous  machine-readable  language  be 
developed.  By  employing  an  unambiguous  language  which  is 
translated  and  analyzed  by  a  program  intolerant  of 
ambiguity,  a  precise  statement  of  requirements  was  ensured. 

Analysis  of  the  requirements  statemerts,  through  use  of 
static  and  dynamic  decomposition  of  the  individual 
statements  and  analysis  of  the  composite  flow  of  data  and 
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processing,  urovides  an  Internal  consistency  check.  Physical 
universe  consistency  is  ensured  by  converting  the 
specification  into  a  model  which  is  tested  against  a  model 
of  the  real  world.  These  checks  help  to  validate  the 
software  specification  before  it  is  imposed. 

The  use  of  selective  documentation  and  analysis  of  the 
software  specifications,  when  coupled  with  sound  engineering 
and  management  techniques,  provide^  predictability  in  the 
specification  process  and  aids  in  avoiding 
overspecification . 

P.  OVERVIEW  OF  REVS  COMPONENTS 

The  Requirements  Engineering  Validation  System  (REVS)  is 
composed  of  three  major  components  (  Figure  2.  ): 


1.  Requirements  Statement  Language  (RSL)  translator 

2.  Abstract  System  Semantic  Model  (ASSM),  a  centralized 
database. 

3.  A  set  of  automated  tools  for  processing  the 
information  held  by  the  ASSM. 
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The  entire  system  is  based  on  the  ASSM,  a  relational 
database  similar  in  concept  to  that  used  by  the  PSL/PSA 
system  developed  at  the  University  of  Michigan.  Though  the 
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concepts  are  similar,  the  implementations  differ  due  to  the 
need  for  extensibility,  configuration  management,  and  for  a 
flow  approach  for  simulation  being  strongly  stressed  in  the 
development  of  SREM . 

The  ASSM  is  the  interface  between  the  Requirements 
Statement  Language  and  the  set  of  automated  analysis  tools. 
This  allows  the  extension  of  the  language  without  having  to 
take  into  consideration  such  things  as  operating  system 
impact  and  control  of  the  automated  tools.  It  also  allowed 
the  RSL  to  be  developed  as  a  natural  method  in  which  to 
express  requirements?  not  being  constrained  by  control 
languages  or  configuration  management  [12] . 

Besides  providing  a  means  to  naturally  express 
requirements,  the  RSL  also  provides  a  rigorous  structure 
that  allows  it  to  be  machine-interpretable.  This  is  due  to 
the  fact  that  it  was  designed  around  the  specification  of 
flow  graphs  of  required  processing  steos  [11,  12,  13].  These 
flow  graphs  are  expressed  as  “structures",  the  product  of 


mapping  a  two 

dimensional  graph 

(  Figure 

3.) 

onto  a 

one 

dimensional 

input  stream 

(Figure 

4.) 

[12]. 

The 

aforementioned 

extensibility  allows  the  modification  of 

the 

RSL  to  suit  particular  requirements  and  provides  a  means  to 
accomodate  new,  unanticipated  needs  for  stating  requirements 
including  non-procedural  statements.  The  RSL  statements  and 
structures,  once  entered,  are  abstracted  and  entered  into 
the  ASStf  where  they  can  be  used  by  the  automated  system 
tools. 
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R_NET:  PROCESS_RADAR_RETURN. 

STRUCTURE: 

EXTRACTJVIEASUREMENT 
DO  (STATUS1*  VALID_RETURN) 

DO  'JPD ATE_ST ATE  AND  KALMAN_FILTER  END 
DETERMINE_ELEVATION 
DETERMINE_IF_REDUNDANT 
TERMINATE 
OTHERWISE 

DETERMINE_IF_OUTPUT_NEEDED 
DO  DETERMINE_IF_REDUNDANT. 

DETE  RM I NE  _E  LE  VATI  ON, 

TERMINATE 

AND  DETERMINED  F_GHOST, 

TERMINATE 

END 

END 

END. 


Figure  4. 
Input  Stream 
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The  automated  syster  tools  include:  interactive  graphics 
to  aid  in  development,  specification,  and  modification  of 
flow  graphs;  static  consistency  checkers  used  to  ensure 
internal  consistency  in  specifications;  and  an  automated 
simulator  generator  and  execution  package  which  aid  in 
dynamic  testing. 

These  tools  also  ensure  that  portions  of  system 
specified  later  than  some  segments  will  he  consistent  since 
their  connectivity  with  the  early  segments  was  defined  at 
the  highest  levels.  This  is  a  particularly  attractive 
feature  as  it  allows  system  design  to  progress  without  all 
segments  developing  at  the  same  pace  and  allows  several 
persons  to  participate  in  the  design  process.  Additionally, 
any  extensions  of  the  system  are  forced  to  he  compatible 
with  all  prior  specifications  since  any  incompatibility 
would  preclude  entering  the  extension  into  the  ASSM. 

The  next  several  sections  will  go  into  greater  detail  as 
to  some  of  the  specific  mechanics  employed  by  the 
aforementioned  components.  This  information  is  derived  from 
the  papers  by  Alford  et  al.  Ell]  and  Bell,  Bixler,  and  Dyer 
[12]. 

E.  REQUIREMENTS  STATEMENT  LANGUAGE 

Chapter  III  pointed  out  the  findings  of  Jones  f9] ;  that 
the  use  of  English  for  documentation  and  specification  is 
too  often  unsatisfactory  due  to  the  ambiguity  inherent  in 
the  language.  Alford  [14]  noted  the  Inability  to  provide  an 
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effective  means  of  ensuring  traceability  and  testability  of 
requirements?  that  in  nearly  every  software  project  that  has 
failed,  the  requirements  were  accused  of  being  late, 
incomplete,  over-constraining,  or  just  plain  wrong.  In  order 
to  overcome  these  and  other  problems  the  first  of  three 
goals  established  during  the  initial  development  of  SBEm  was 
to  develop  a  language  for  stating  requirements  that 
addressed  the  properties  of  unambiguity,  design  freedom, 
testability,  modularity  and  communicability  [14]. 

The  language  that  evolved,  ?SL,  is  an  artificial 
language  that  incorporates  naturalness  of  expression. 
Through  use  of  the  flow  approach  to  defining  requirements, 
it  provides  information  on  how  pieces  of  the  system  will  fit 
together,  something  not  possible  when  the  hierarchy  of 
functions  approach  to  specifying  requirements  is  employed. 
Additionally,  since  the  language  can  precisely  define 
concepts  and  constrains  the  semantics  to  a  simple  level  of 
detail,  the  risk  of  ambiguity  is  significantly  reduced  and 
only  the  true  requirements  of  the  system  evolve. 

1.  Flows 

The  traditional  hierarchy  of  functions  approach  to 
requirements  specifications,  currently  mandated  in  DOP 
MIL-STD  490,  describes  the  operations  that  each  module  is 
expected  to  perform,  rendering  the  requirements  to  little 
more  than  program  specifications.  This  method  fails  to 
adequately  address  the  sequence  of  operations  and  the 
communication  between  modules,  thus  creating  problems  with 
real-time  systems.  In  order  to  overcome  this,  RSL  is 
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structured  to  represent  a  stimulus/response  approach  or  a 
"flow”.  Each  flow  is  initiated  by  seme  "stimulus"  or  input 
and  cascades  down  through  the  various  functions,  producing 
the  appropriate  response  until  the  processing  is  completed. 
By  utilizing  this  approach  the  exact  sequence  of  orocesses 
becomes  explicitly  thereby  enhancing  testability. 

The  flows,  commonly  known  a  Requirements  Networks  or 
R-N’ets,  consist  of  nodes,  which  specify  an  operation,  and 
their  connecting  arcs.  The  basic  nodes  consist  of  ALPHAS, 
which  are  the  specifications  of  functional  processing  steps, 
and  SUBNETS,  which  are  specifications  of  processing  flows  at 
a  lower  level  in  the  hierarchy.  As  noted  previously,  these 
nodes  are  single  entry,  single  exit,  however,  rore  complex 
flows  may  be  specified  by  use  of  structured  nodes  which 
enable  the  system  to  execute  multiple  flow  paths.  These 
structured  nodes  include  AND,  OR,  and  FOR  EACH. 

The  AND  node  specifies  that  its  eminating  arcs 
leading  to  further  nodes  are  mutually  order-independent, 
able  to  be  executed  sequentially  in  any  order  or  in 
parallel.  The  rejoining,  or  fan  in,  of  the  arcs  at  the  end 
of  the  AND  structure  specifies  a  synchronization  point*  the 
execution  of  the  processes  as  specified  by  each  path  in  the 
structure  must  be  completed  in  order  to  trigger  an  output 
from  the  structure. 

The  OR  node  is  similar  to  the  IF-THEN-ELSE  construct 
in  structured  programming.  The  complete  execution  of  all 
processes  specified  on  any  or  all  paths  will  trigger  an 
output  from  this  structure. 


The  FOR  FACH  node  is  similar  to  a  loop  construct  in 
structured  programming.  It  has  only  one  processing  path  and 
the  number  of  times  that  this  path  is  looped  through  is 
based  on  the  number  of  elements  contained  in  a  set.  For 
example,  in  a  tracking  problem  an  update  in  the  range  for 
each  target  may  be  requested. 


Because 

the 

syntactic 

structure  of 

the 

R-Nets  is 

similar  to  that 

of 

structured 

programming. 

it 

aids  the 

requirements  engineer  in  determining  areas  that  are  vague  or 
ambiguous,  in  communicating  with  others,  and  in  utilizing 
automated  analysis  tools. 

2 .  Extensions 

As  mentioned  previously,  SSL  incorporates  the 
concept  of  extensibility  so  that  new  concepts  that  may 
develop  in  the  future  may  be  easily  integrated  into  the 
existing  system.  The  requirements  of  real-time  systems  is 
one  of  the  primary  forces  behind  the  dynamic  nature  of 
state-of-the-art  developments  in  digital  processing  and 
computing.  Coupled  with  the  evolutionary  nature  of  weapons 
systems  requirements,  such  as  new  Interfacing  or  processing 
techniques,  the  situation  would  clearly  render  a  language 
with  fixed  concepts  ineffective. 

By  keeping  the  underlying  architecture  of  RSL  simple 
it  has  been  possible  to  incorporate  extensibility  through 
use  of  four  primitives: 

e.  Elements 

Elements  are  the  equivalent  of  nouns  in  English 
and  describe  the  properties  of  each  element.  Elements 


Include  ALPHA,  DATA  (class  of  conceptual  pieces  of  lata), 
and  R-NET  (class  of  processing  flow  specif  icati  or.s ) . 

b.  Relationships 

These  are  the  equivalent  of  English  verbs  or 
rore  precisely  a  statement  of  association  between  two 
elements  such  as  DATA  INPUT  TO  ALPHA.  It  should  be  noted 
that  this  is  a  non-commutati ve  relation?  a  distinct  subject 
and  object  element  are  expressed. 

c.  Attributes 

Attributes  are  similar  to  adjectives  in  English 
are  used  to  formalize  important  properties  of  elements. 
Associated  with  it  are  a  set  of  values  which  may  include 
numbers,  mnemonic  names,  or  text  strings.  INITIAL  VALUE  and 
PRESENT  RANGE  are  examples  of  attributes  of  type  DATA. 

d.  Structi'res 

Structures  are  the  mapping  of  two-dimensional 
graph  structures  into  a  one-dimensional  stream  of  computer 
input.  They  serve  as  a  model  of  flows  through  the  various 
processing  steps. 

As  noted  above,  these  four  primitives  define  the 
structure  of  RSL.  The  structure  in  itself  is  not  extensible? 
however,  the  primitives  enable  the  user  to  define  new  types 
of  elements,  relationships,  and  attributes  into  the  language 
in  order  to  express  new  concepts. 

Figure  5  gives  an  example  of  how  ALPHA,  DATA, 
RELATIONSHIPS,  and  new  elements  are  defined. 


ALPHA:  E  XTRACT  _ME  ASU  REM  ENT . 

INPUTS:  CORRELATED_RETURN. 

OUTPUTS:  VALID_RETURN,  MEASUREMENT. 

DESCRIPTION:  “DOES  RANGE  SELECTION  PER 
CISS  REFERENCE  2  -  7". 

ENTERED  BY:  “M.  RICHTER”. 

ALPHA:  DETERMINE_IF_REDUNDANT. 

INPUTS:  CORRELATED_RETURN. 

OUTPUTS:  REDUNDANT_IMAGE. 

DESCRIPTION:  “THE  IMAGE  OF  THE  RADAR  RETURN 
IS  ANALYZED  TO  DETERMINE  IF  IT  IS 
REDUNDANT  WITH  ANOTHER  IMAGE”. 

ENTERED  BY:  “F.  BURNS”. 

DATA:  MEASUREMENT. 

INCLUDES:  RANGE_MARK_TIM £,  AMPLITUDE, 
RANGE  ^VARIANCE,  RD  VARIANCE, 

'  R_AND_RD  CORRELATION. 

DESCRIPTION:  “THIS  IS  THE  ESSENCE  OF  THE 
INFORMATION  IN  THE  RETURN”. 

ENTERED  BY:  “F.  BURNS”. 

ORIGINATING  REQUIREMENT: 

DPSPR_3_2_2_A_  FUNCTIONAL. 

DESCRIPTION:  “ACTION:  SEND  RADAR  ORDER 
INFORMATION:  RADAR  ORDER.  IMAGE 
(REDUNDANT)”. 

TRACES  TO:  ALPHA  COMMAND _PULSES 

ALPHA  DETERMINE_IF_REDUNDANT 
MESSAGE  RADAR_ORDER_MESSAGE 
DATA  REDUNDANT_IMAGE 
ENTITY  IMAGE. 

ENTERED  BY:  “T.E.  BELL”. 


Figure  5. 

RSL  Definitions 
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3 .  Translator 

The  ourpose  of  the  translator  is  to  analyze  RSL 
statements  and  make  entries  into  the  ASSM  corresponding  to 
the  meaning  of  the  statements.  It  accomplishes  this  by 
extracting  the  RSL  primitives  which  exist  in  the  input 
statements  and  then  mapping  them  to  constructs  in  the  ASSM. 
The  translator  can  also  perform  modifications  and  deletions 
from  the  database  as  commanded  by  RSL  statements  and  also 
perform  consistency  check  on  the  incoming  statement  to 
prevent  duplication  of  element  name  or  an  illegal 
relationship.  Additionally,  it  also  handles  the  introduction 
of  extensions  with  great  care;  the  introduction  may 
Invalidate  a  large  segment  of  the  requirements.  For  this 
reason  a  lockout  mechanism  was  designed  to  control  the  use 
of  extensions  and  enforce  a  disciplined  use  of  the  power  of 
SSL. 

F.  THF  ABSTRACT  STSTEM  SEMANTIC  MODEL  (ASSM) 

The  RSL  statements  that  are  entered  into  REVS  are 
analyzed  and  their  representation  is  entered  into  the  ASSM, 
a  database  that  maintains  information  about  the  system  being 
designed  in  an  abstract,  relational  model.  Since  checks  are 
made  for  syntax  and  semantics  before  information  is  entered, 
it  is  possible  to  employ  the  various  tools  or  REVS,  assured 
of  data  format  correctness.  Also  included  in  the  ASSM 
entries  are  all  extensions,  including  core  concepts  (basic 
RSL)  and  additions  and  modifications  to  specific  projects. 
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They,  too,  are  available  for  immediate  use  as  soon  as  they 
are  entered. 

The  information  contained  in  the  A S SM  is  not  simply  a 
string  of  RSL  statements.  Rather,  it  is  a  relational  model 
where  elements  are  represented  by  nodes  and  their 
relationships  are  represented  as  connections.  Attributes  and 
their  values  consist  of  a  node  for  the  value  and  a 
connection  to  the  node  for  which  the  value  is  attributed. 
This  representation  facilitates  retrieval  of  information, 
particularly  in  complex  combinations  of  relationships  and 
permits  queries  about  specific  information  or  relationships 
such  as  finding  all  DATA  elements  which  are  not  INPUT  TO 
anything. 

The  centralization  of  information  in  the  ASSf*  is 
mandatory  due  to  the  large  numbers  of  individuals  who  enter 
additions,  deletions,  and  modifications  to  the  various 
system  recuirements .  This  centralization  ensures  that  all 
involved  are  working  with  a  repository  of  information  that 
is  current;  they  can  immediately  see  the  effect  of  their 
work  on  other  engineers,  the  characteristics  of  parts  of  the 
system  that  other  people  are  defining,  and  the  current 
status  of  their  own  work.  In  addition,  centralization  aids 
in  configuration  management  (where  blocking  of  modifications 
freezes  the  configuration)  and  in  checking  for  consistency 
throughout  the  entire  system. 


G.  AUTOMATED  TOOLS 


Tor  laree  software  projects,  it  is  necessary  to  employ 
the  services  of  many  individuals  to  develop  requirements  for 
different  segments  of  the  system;  each  formulating  the  RSL 
descriptions  for  his/her  particular  part  of  the  system.  The 
mechanisms  for  imposing  discipline  and  control  on  this 
process  are  the  automated  tools  provided  by  REVS.  These 
tools  aid  the  engineer  in  identifying  the  various  areas  that 
require  further  development,  resolve  conflicts,  and  evaluate 
inputs.  Since  the  requirements  engineering  process  is  of  an 
iterative  nature,  these  tools  help  to  evaluate  the  entire 
system  when  various  milestones  are  reached. 

1 .  Interactive  Graphics 

The  interactive  graphics  facility  of  ^EVS 
enables  the  engineer  to  input,  modify,  or  display  R-NETS.  It 
is  possible  to  use  it  in  lieu  of  the  translator  for  the 
specification  of  the  flow  portion  of  the  requirements  and  it 
can  be  used  to  generate  a  graphic  display  of  an  R-NET 
previously  entered.  The  two-dimensional  nature  of  graphics 
serves  to  provide  a  more  easily  understood  representation 
than  a  one-dimensional  input  stream*  however,  the  facility 
allows  the  use  of  both  graphics  and  the  RSL  language  for 
representation  of  the  R-NETs. 

Along  with  the  graphics  are  a  full  range  of 
editing  capabilities.  A  new  R-NET  may  be  constructed  or  one 
previously  entered  may  be  modified.  At  the  end  of  the 
session  the  new  R-NET  is  entered  into  the  ASSM  in  place  of 


the  old  one.  Trom  a  menu,  the  user  may  select  functions  to 


position,  connect,  and  delete  nodes,  to  move  them, 
disconnect  them  from  other  nodes,  or  to  charge  their 
associated  name  and  commentary.  Finally,  the  size  of  an 
F-NET  is  not  size-limited  due  to  the  zoom-in,  zoom-out,  and 
scroll  functions. 

2 .  Simulation 

Simulation  offers  an  effective  means  by  which  to 
test  consistency,  completeness,  and  validity  of 
requirements.  The  building  of  simulations  must  be  automatic 
to  preclude  divergence  of  the  requirements  from  the 
simulation  and  to  allow  rapid  response  and  analysis  of 
change . 

The  automatic  simulation  generation  in  SFVS 
takes  the  ASSm  representation  of  the  requirements  and 
generates  from  it  simulations  of  the  system.  The  System 
Environment  and  Threat  Simulation  (SETS)  program  is  the 
driver  for  the  software  requirements  model. 

SETS  provides  all  stimuli  necessary  for  each 
processing  option  and  also  accepts  and  properly  executes  all 
valid  commands.  SETS  is  structured  to  simulate  the  required 
actions,  calculate  how  long  the  activity  would  have  taken  in 
a  real  system,  and  make  the  results  of  the  activity 
available  to  the  software  at  the  proper  simulated  time. 
Because  of  the  asynchronous  nature  of  real-ti^e  systems, 
E-NET  timing  is  implicitly  modeled. 

SETS  takes  the  ASSK  representation  of  the 


requirements  and  puts  them  into  simulation  code  written  in 
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PASCAL.  The  flow  structure  of  each  R-NET  is  used  to  develop 
a  PASCAL  procedure  whose  control  i'-olement  s  that  of  the 
R-NET  structure.  Each  processing  step  (ALPHA)  or.  the  R-NET 
hecofres  a  call  to  procedure  consisting  of  the  model  or 
algorithm  for  the  ALPHA.  The  data  definitions  and  structure 
for  the  simulation  are  synthesized  from  the  required  data 
elements,  their  relationships,  and  their  attributes  in  the 
ASSK. 

Z .  Static  Analysis 

Since  most  requirements  inconsistencies  do  not 
require  simulation  for  their  discovery,  REVS  provides 
several  tools  to  statically  check  for  completeness  and 
consistency.  They  are  able  to  detect  deficiencies  in  the 
flow  of  processing  and  data  manipulation  stated  in  the 
requirements. 

The  first  class  of  these  tools  is  to  check  the 
structure  of  the  R-NETS  entered  interactively,  including  one 
and  only  one  start  node,  proper  branching  and  rejoining  of 
paths,  and  their  proper  termination. 

The  second  class  of  tools  checks  the  flow  of 
data  through  the  R-NETS.  They  check  for  definite  and 
potential  errors  in  data  use. 

The  third  class  of  tools  checks  for  proper 
hierarchy  in  the  specification.  Definitions  rust  be 
specified  for  all  SUBNETS,  that  SUBNETS  must  not  make 
reference  to  each  other  recursively,  and  that  all  ALPHAS  and 
SUBNETS  must  appear  on  at  least  one  R-NET. 


In  order  to  reduce  the  necessity  of  adding  a  new 
tool  each  time  a  specialized  report  or  analysis  is  required, 
PEVS  provides  the  requirements  engineer  with  a  specialized 
tool  known  as  the  "extractor".  The  exactractor  enables  the 
user  to  control  the  scope  of  the  analysis  and  content  of  the 
reports  generated,  not  burdening  him  with  format 
specif ication  or  the  need  to  review  tabular  forms  to  extract 
inf orma  tion . 

This  system  enables  the  user  to  subset  elements 
in  the  ASSM  based  on  some  condition  or  conditions  and  then 
display  the  subset  elements.  The  output  produced  is  in  RSL 
compatible,  standardized  format  to  which  prepositions  and 
punctuation  are  added  to  produce  formal  documentation. 

The  information  the  user  desires  to  be  retrieved 
is  identified  in  terms  of  RSL  concepts.  For  example: 

SET  A  =  DATA  INPUT  TO  KALMAN-FILTFR . 

LIST  A. 

By  combining  and  manipulating  these  sets  it  is  possible  to 
detect  the  presence  and  absence  of  data,  trace  references, 
and  analyze  interrelationships. 

The  extractor  provides  both  reports  for  ad  hoc 
inquiries  and  routinely  generated  special  reports  which 
enable  managers  to  check  for  completeness  and  consistency, 
and  perform  automatic  regressive  testing. 


A.  INTRODUCTION 


The  survey  discussed  in  the  next  chapter  revealed  that 
many  commands  In  the  U.S.  Navy  interested  in  RSL  have  used 
the  Problem  Statement  Language/Problem  Statement  Analyzer 
(PSL/PSA)  system.  For  that  reason  a  brief  overview  of  this 
system  will  presented,  as  well  as  a  section  that  deals  with 
some  of  the  drawbacks  of  both  SREM  and  PSL/PS/ . 

B.  PSL/PSA  OVERVIEW 

PSL/PSA  [15]  was  designed  to  provide  an  improved 
approach  to  system  design.  This  approach  is  based  on  the 
premise  that  more  effort  and  attention  should  be  devoted  to 
the  front  end  of  the  process  where  a  proposed  system  is 
being  designed  by  the  potential  user;  that  since  large 
amounts  of  information  are  being  handled,  a  computer  should 
be  used;  that  computer-aided  approaches  to  system 
development  must  start  with  documentation. 

The  system  is  based  on  a  counterpart  of  RSL,  namely  PSL 
or  Problem  Statement  Language.  It  is  based  on  a  model  of  a 
general  system  and  also  on  the  specialization  of  the  model 
towards  Information  systems  . 


Puch  Hire  SREK,  PSL  defines  a  set  of  OBJECTS  which  have 
PROPERTIES  and  PROPERTY  VALUES  and  their  interconnections 
are  referred  to  as  RELATIONSHIPS.  PSL  also  talces  Into 

account  timing  and  volume  considerations. 

The  intent  of  PSL  Is  to  separate  the  definition  of  user 
requirements  and  the  processing  solution  of  these 

requirements  [16],  If  the  two  were  carried  out  In 
concurrently,  requirement  changes  in  the  future  may  not  he 

accomodated  due  to  a  firm  design.  Therefore,  PSL  does  not 

presuppose  solutions,  it  only  states  requirements. 

The  second  half  of  the  system,  the  Problem  Statement 
Analyzer  or  PSA,  performs  basically  the  following  functions: 

1 .  Data  Collection 

Several  Intermediate  outputs  of  the  PSA  include 
checklists  for  deciding  what  additional  Information  Is 
required. 

2.  Analysis 

A  variety  of  analyses  previously  performed 
manually  can  be  handled  by  PSA,  including  static  analysis  of 
the  entire  developed  system. 

3.  Design 

PSA  allows  data  to  be  manipulated  more 
extensively  by  the  designer. 

4.  Evaluation 

PSA  can  perform  computations  on  volume  or  work 
measures  from  data  In  the  problem  statements  [151. 
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The  PSA  also  serves  as  a  report  generator.  Including 
narrative  description,  lists,  tables,  arrays,  matrices, 
diagrams,  and  charts.  The  PSA  can  produce  reports  on  what 
changes  have  been  made  in  the  database,  reference  data  items 
of  similar  type  or  property,  or  produce  reports  of 
analytical  nature  such  as  gaps  in  information  flow, 
similarity  of  inputs  and  outputs,  and  the  dynamic  nature  of 
the  system  [15] . 

C.  COMPARISON  OF  SREM  AND  PSL/PSA 

One  of  the  difficulties  in  the  area  of  RSL  is  that  there 
has  been  no  in-depth  comparative  studies  of  the 
effectiveness  of  the  various  systems  and  methodologies.  The 
main  reason  is  readily  apparent:  such  an  endeavor  would  be 
costly  in  terms  of  both  time  and  money  and  the  criteria  for 
Judging  overall  effectiveness  and  usefulness  would  be 
difficult  to  develop.  However,  there  are  some  practical 
aspects  of  SREM  and  PSL/PSA  that  bear  some  scrutiny. 

1 .  Transportability 

SREM,  at  the  moment,  is  highly  machine  dependent 
due  to  memory  hierarchy  mapping  and  that  the  bulk  of  the 
system  operates  with  approximately  60,000  lines  of  PASCAL. 
SREM  is  presently  operating  on  Texas  Instruments  Advanced 
Scientific  Computer  (ASC)  and  certain  models  of  Control  Data 
Corporation's  CDC  7600.  Work  is  presently  underway  to  make 
SREM  compatible  with  Digital  Equipment  Corporation's  VAX-11 
system. 
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PSL/PSA  does  not  have  this  problem.  It  is 
written  in  standard  FORTRAN,  making  it  compatible  with  a 

wide  range  of  computers. 

2 .  Graphics 

With  SREtf,  the  use  of  the  CALCOPP  plotter 
imposes  a  severe  limitation  on  the  number  of  elements  that 
can  be  drawn.  However,  the  on-line  graphics  package,  along 
with  the  features  discussed  in  the  previous  chapter,  have 
demonstrated  good  editing  capabilities  and  fast  turn  around 
[171 . 

PSL/PSA  has  some  strict  limitations  in  graphics. 
First  is  its  representation  of  functional  flow  diagrams, 
called  "process-chains"  (Fig.  6  [17]).  This  type  of 
representation  cannot  show  all  types  of  logic  branching, 
such  as  IF-TEEN-ELSE  type  constructs.  One  has  to  refer  back 
to  the  formatted  problem  statements  to  determine  the  logic 
being  used.  Feedback  cannot  be  represented  as  well  [17], 

PSL/PSA  can,  however,  produce  a  "picture-report” 
(Fig.  7  [17]),  which  is  a  partitioning  of  the  varicus 
processes.  The  picture-report  can  show  what  the  process  is 
part  of.  Inputs  and  outputs,  and  the  entities  the  process 
uses  or  derives.  A  description  of  these  items  can  be  found 
in  the  formatted  problem  statements.  This  report  can  be  very 
useful  to  program  designers  [17], 

It  should  also  be  mentioned  that  PSL/PSA 
utilizes  only  a  line  printer  for  graphics  output  and  that 
development  work  is  being  done  to  interface  both  plotters 


graphics  terminals.  The  use  of  line  printers  for  the  graphic 
output  has  caused  difficulty  In  readability. 

3.  Simulation 

SREM's  static  and  dynamic  capabilities  were 
described  in  the  preceeding  chapter. 

PSL/PSA,  at  present,  has  no  simulation 
capability,  but  development  work  is  underway  to  implement 
this  feature  utilizing  SIMSCRI?  II. 5.  [fur]. 

4 .  Other  Considerations 

As  described  previously,  SREM  was  developed  for 
large,  real-time  systems.  The  approach  taken  in  the 
development  of  PSL/PSA  was  more  universal:  the  system  was 
aimed  towards  utilization  by  a  wide  range  of  users. 


VI.  UTILIZATION  OF  RSL  IN  TPF  U.S.  NAVT 


A.  INTRODUCTION 

A  sizeable  portion  of  the  research  behind  this  thesis 
was  spent  in  conducting  a  telephone  survey  of  various  naval 
centers  engaged  in  research  and  development.  The  centers 
contacted  were: 

1.  Naval  Research  Laboratory,  Washington,  D.C. 

2.  Naval  Air  Development  Center,  Warminster,  Pa. 

3.  Fleet  Combat  Direction  Systems  Support  Center, 

San  Diego,  Ca . 

4.  Naval  Oceans  Systems  Center,  San  Diego,  Ca. 

5.  Naval  Surface  Weapons  Center,  Tahlgren,  Va. 

6.  Naval  Underwater  Systems  Center,  New  London,  Conn. 

The  purpose  of  the  survey  was  to  ascertain  the  current 
level  of  utilization  of  requirements  statement  languages  in 
system  design  and  development.  The  personnel  contacted  were 
questioned  as  to  which  RSL  and/or  methodology  was  currently 
being  employed,  to  what  type  of  project  it  was  being 
applied,  perceived  or  proven  successes  and  failures,  how 
much  interest  has  been  expressed  by  higher  authority,  and 
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their  personal  assessment  as  to  the  future  of  such  tools  in 
system  specification,  design,  and  development.  A  summary  of 
the  findings  follows,  however,  the  views  expressed  should 
not  and  cannot  he  taken  as  the  official  position  of  the 
individual  commands. 

B.  NAVAL  RESEARCH  LABORATORY  (NRL) 

Other  than  some  work  performed  for  the  Applied  Physics 
Laboratory,  The  Johns  Hopkins  University,  in  1378,  utilizing 
SREM,  there  has  been  little  interest  expressed  in  RSL  per 
se.  However,  Heninger  et  al .  [18]  have  advanced  the  notion 
of  developing  a  disciplined  methodology  in  order  to  develop 
clear,  concise  requirements  specifications  through  their 
work  in  redesigning  and  rebuilding  the  operational  flight 
program  for  the  A-7  aircraft. 

It  is  their  contention  that  it  is  necessary  to  approach 
such  a  problem  by  formulating  questions  before  answering 
them,  rather  than  being  influenced  by  available  information, 
separating  concerns,  and  using  precise  notation  [7]  .  From 
these  basic  principles  they  developed  their  disciplined 
approach  which  is  more  fully  discussed  in  [7]  and  [18]. 

C.  NAVAL  AIR  DEVELOPMENT  CENTER  (NADC ) 

NADC  was  introduced  to  RSL  when  it  was  directed  by  Naval 
Air  Systems  Command  (NAVAIR)  in  1978  to  install  and  utilize 
SREM  In  conjunction  with  the  CV/TSC  project  (since 
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redesignated  CY/ASWM ) »  an  effort  to  develop  a  computer-based 
tactical  support  center  for  S-3A  aircraft  to  be  integrated 

with  the  Naval  Tactical  Data  System  (NTDS). 

Problems  with  the  utilization  of  SHEW  were  caused  by  its 
being  introduced  too  late  in  the  development  phase. 
Personnel  were  not  comfortable  with  it  and  there  seemed  to 
be  a  lack  of  unanimity  among  these  same  personnel  as  to 
whether  or  not  the  SHIM  approach  to  system  design  was 
viable . 

Though  no  further  projects  have  utilized  SREM.  several 
internal  studies  have  been  conducted  at  NADC  aimed  at 
determining  its  feasibility  for  future  projects.  The  interim 
findings  have  suggested  that  SREM  or  sore  similar 
methodology  should  be  more  actively  incorporated  into  the 
requirements  definition  phase  of  system  development.  The  Air 
Force's  Rome  Air  Development  Center  (HADC),  Griffiss  Air 
Force  Base,  New  York,  will  soon  send  personnel  to  NADC  for 
developmental  work  with  SREM. 

D .  FLEET  COMBAT  DIRECTION  SYSTEMS  SUPPORT  CENTER  (FCPSSA) 

FCDSSA  has  looked  closely  at  the  problem  of  requirement 
level  documents  as  they  are  currently  developed  and  at  the 
use  of  methodologies  and  automated  tools  in  defining  and 
analyzing  requirements  for  tactical  data  system  software. 
Their  study  of  requirement  level  documents  revealed  the  lack 
of  conformity  in  terminology,  such  as: 


-  different  words  and  phrases  used  to  convey  the  same 
meaning. 

-  same  words  and  phrases  used  to  convey  different 
meanings . 


-  slightly  different  words  and  phrases  used  with 
only  slightly  different  meanings. 


-  different  disciplines  such  as  navigation, 
sensors,  aviation,  fire  control,  etc.  having 
different  terminology,  complicating  their 
integration  into  the  overall  system. 

Additionally,  too  often  the  applicability  to  subsystems; 
the  conditions,  external  and  Internal,  under  which  the 
requirements  apply;  and  the  duration  of  their-  applicability 
are  ill-defined. 

JCDSSA  feels  that  any  proposed  methodology  should 
include: 

-  disciplined  requirements  statement  language. 

-  extensive  use  of  graphics  to  facilitate  communication. 

-  model  building  techniques  for  verifying  completeness. 

Above  all,  it  is  felt  that  it  is  the  methodology,  not  the 
tools  employed,  that  is  of  the  greatest  importance. 

Since  early  1978,  7CDSSA  has  evaluated  several  systems 
utilizing  RSI,  including  SREM  and  PSL/PSA.  It  noted  the 
strong  and  weak  points  of  each  system  and  decided  that  none 
provided  the  flexibilty,  user  interaction,  and  ease  of  use 
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that  it  thought  to  he  mandatory.  Therefore,  it  embarked  in 
late  1976  on  the  development  of  its  own  requirements 
language  analyzer,  named  CORVAIR.  The  eventual  aim  is  to 
produce  a  system  with  a  highly  extensible  language  that  can 
be  configured  to  suit  the  needs  of  the  individual  and  that 
will  ultimately  produce  source  code  from  the  requirements 
automatically. 

It  was  mentioned  that  the  requirements  developed  for  a 
project  utilizing  a  system  using  RSL  were  not  accepted  by  a 
contractor;  it  was  felt  by  the  contractor  that  the  system 
was  already  designed  by  FCDSSA.  It  was  the  opinion  of  the 
person  contacted  at  FCDSSA  that  an  effort  is  needed  to 
educate  all  parties  in  the  government  and  civilian  sectors 
as  to  exactly  what  the  purpose  of  RSL  developed 
specifications  serve. 

E.  NAVAL  OCEAN  SYSTEMS  CENTER  (NOSC) 

The  System  Design  Laboratory  at  NOSC  found  PSL/PSA  to  be 
of  great  use  in  enforcing  discipline  in  the  way  requirements 
specifications  are  written.  As  an  example,  they  checked  the 
specifications  of  the  NTDS  Model  4  software  for  FCDSSA, 
using  PSL/PSA.  Their  analysis  uncovered  over  200  occurances 
of  ambiguous,  undefined,  or  inconsistent  statements. 

A  feature  of  PSL/PSA  that  was  very  well  received  was  the 
ability  to  store  the  developed  requirements  specif ications 
in  a  database  and  the  ability  to  partition  specifications  in 


order  to  determine  the  effect  that  any  modification  would 
have  on  the  overall  system. 

NOSC  has  not  received  much  direction  as  to  the  use  of 
PSL/PSA  or  any  other  RSI.  NOSC  has,  however,  been  a  strong 
proponent  of  such  a  system  and  has  conducted  seminars  for 
government  and  civilians  in  the  San  Diego  area.  The 
personnel  involved  feel  that  it  is  an  area  that  should  be 
actively  pursued  and  developed. 

One  of  the  problems  noted  was  the  difficulty  of  mapping 
PSD  developed  requirements  into  the  structure  required  by 
SECNAVINST  3560.1. 

F.  NAVAL  SURFACE  WEAPONS  CENTER 

The  Naval  Suface  Weapons  Center  is  presently 
incorporating  PSL/PSA  into  the  life  cycle  support  of  the 
AEGIS  combat  systems.  Their  initial  work  has  centered  around 
the  retrofitting  of  AEGIS  specifications  into  PSL  so  as  to 
verify  and  validate  the  system  at  least  on  a  high  level.  It 
is  hoped  in  the  future  the  work  will  be  focused  on  lower 
levels  of  the  system  to  check  the  stimulus/response  of 
individual  modules  and  eventually  Investigate  the  automated 
generation  of  performance  specifications. 

PSL/PSA  has  been  very  well  received  by  personnel  at  the 
center.  They  very  much  feel  that  this  is  the  direction  in 
which  requirements  definition  in  the  system  design  should 
proceed.  Briefings  on  this  technique  have  been  given  to 


officials  from  Washington,  D.C.  and  they,  in  turn,  have 
expressed  some  interest  in  its  development. 

Problems  noted  by  the  center  were  the  need  of  educating 
personnel  as  to  the  techniques  involved  and  the  faci  that 
SECNAVINST  3563.1  does  not  facilitate  the  use  of  RSL 
generated  specifications  because  this  instruction  predates 
the  development  of  RSL. 

C-.  NAVAL  UNDERWATER  SYSTEMS  CENTER  (NUSC) 

The  experience  at  N'USC  with  RSL  has  been  limited  to  the 
IBM  Federal  Systems  Division's  work  on  the  Submarine  Active 
Detection  Sonar  (SADS)  project  using  PSL/PSA. 

The  project,  as  far  as  utilization  of  PSL/PSA,  proved  to 
be  unsuccessful  and  was  finally  abandoned.  The  person 
contacted  at  NUSC  listed  as  some  of  the  problems: 

-  personnel  at  NUSC  were  not  sufficiently  familiar 
with  PSL/PSA  to  fully  appreciate  its  capabilites 
and  peculiarities. 

-  due  to  security  considerations  and  the  fact  that 
the  host  IBM  370  computer  had  to  be  shared  with 
others,  forcing  third  shift  operations,  there 
existed  a  time  constraint  on  development  work. 

-  the  output  produced  was  hard  to  understand. 

-  there  were  constraints  imposed  by  SECNAVINST 
3560.1  that  could  not  be  waived. 


IB!-  Federal  Systems  Division  was  contacted  for  its  views 
on  the  problems  with  the  use  of  PSL/PSA  and  SADS.  They 
noted : 


personnel  were  not  sufficiently  familiar  with 
PSL/PSA. 


there  was  poor  support  for  the  tool  as  it  had 
been  only  recently  installed. 


-  adequate  training  was  not  received  by  personnel 
involved  in  the  use  of  the  system. 


there  is  extreme  difficulty  in  attempting  to 
translate  PSL/PSA  generated  requirements  into 
the  narrative  form  required  by  SFCMAVIMS? 
3560.1. 


The  personnel  contacted  at  IBM  Federal  Systems  Division 
said  that  they  felt  that  PSL/PSA  would  be  of  significant 
value  on  future  government  projects.  They  are  confident  that 
most  of  the  problems  experienced  on  the  SAD S  project  will  be 
corrected . 


H.  SUMMARY 

The  survey  conducted  revealed  several  views  that  were 
expressed  by  the  majority  of  the  personnel  interviewed.  They 
were: 


the  use  of  RSL  has  forced  discipline  in 
specification  writing.  As  a  consistency  checker, 
it  has  uncovered  numerous  errors  in  critical 
documents. 
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the  concept  and  use  of  RSL  should  be  continued 
and  expanded  in  future  projects. 


there  exists  an  education  gap  in  both  the 
government  and  civilian  industry  as  tc  the  use 
of  RSL.  This  is  a  problem  that  must  be  resolved 
so  as  to  avoid  the  misunderstanding  and 
misapprehension  experienced  in  the  past. 


strong  management  support  is  required  to 
overcome  the  tendency  by  some  to  resist  change, 
regardless  of  how  oroven  a  new  technology  may 
be. 


though  not  addressed  in  the  above  sections,  the 
majority  felt  it  would  benefit  the  government  to 
utilize  RSL  early  in  the  conceptual  phase  of  a 
project  instead  of  introducing  its  use  after  the 
specifications  have  been  written.  A  conversation 
with  Dr.  Teichroew,  one  of  the  prime  developers 
of  PSL/PSA,  revealed  that  the  vast  majority  of 
private  sector  users  of  his  system  use  it  from 
project  inception. 


it  is  extremely  difficult  to  translate  RSI 
generated  specifications  into  the  form  required 
by  SECNAVINST  3560.1. 
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VII 


RSL  AND  SYSTEM  ACQUISITION 


It  Is  Important  to  examine  how  RSL  methodologies  fit 
into  the  various  rules,  regulations,  directives,  and 
standards  that  currently  govern  systems  acquisition  in  the 
Department  of  Defense  and  the  U.S.  Navy.  It  would  he  neither 
possible  nor  meaningful  to  examine  every  document  dealing 
with  this  area,  nor  would  it  he  possible  to  do  an  in-depth 
analysis  of  each.  Rather,  it  is  the  intent  of  this  chapter 
to  look  at  some  of  the  major  points  stressed  in  the  above 
rules,  regulations,  etc.  and  determine  whether  or  not  RSL 
methodologies  satisfy  the  letter  and  intent  of  these 
documents  from  both  the  government  and  the  contractor  points 
of  view  and  to  consider  changes  which  may  be  necessary  to 
better  incorporate  the  capabilltes  of  ’SL  methodologies. 

A.  0MB  CIRCULAR  NO.  A-109 

Cn  April  5,  1976,  the  Office  of  Management  and  Budget 
Issued  Circular  No.  A-109,  "Major  Systems  Acquisition" [19] , 
to  the  heads  of  all  Executive  departments  in  the  government. 
The  purpose  of  A-139  was  to  give  strict  guidance  in  the 
acquisition  of  major  systems.  It  stressed:  (1)  Justification 
of  the  acquisition  based  on  mission  need,  not  the  perceived 
need  of  new  hardware,  software,  etc.,  (2)  competitive 
development  of  alternate  solutions  to  solve  the  mission 


need,  (3)  tradeoffs  between  cost,  performance,  and 
production  schedules,  (4)  ensuring  adequate  test  and 
evaluation  of  the  new  system,  and  (5)  development  of  a  sound 
acquisition  strategy,  looking  at  the  entire  life  cycle. 

P.  DEPARTMENT  OE  DEFENSE  DIRECTIVES  5300.1  AND  5000.2 

The  Department  of  Defense's  implementation  of  A-109  was 
Department  of  Defense  Directive  (DODD)  5300.1,  "major 
Systems  Acquisition”,  and  DODD  5000.2,  "Major  Systems 
Acquisition  Process".  In  both  of  these  directives  are  areas 
in  which  an  FSL  methodology  may  prove  beneficial. 

1 .  Technology  Base 

DODD  5000.1  tasks  each  DOD  Component  Head,  such  as 
the  Secretaries  of  the  Army,  Navy,  and  Air  Force,  with 
advancing  technology  lr.  both  product  and  manufacturing 
technology  to  support  future  system  development.  It  is 
recommended  that  the  methodology  employed  in  designing  and 
developing  software  should  certainly  be  incorporated  into 
this  base.  As  EOD's  level  of  experience  with  the  use  of  a 
formal  methodology  in  the  design  and  development  of  software 
grows,  it  certainly  is  quite  feasible  that  modifications  to 
the  methodology  may  be  warranted,  certainly  in  the  critical 
area  of  real-time  systems.  This  inclusion  in  the  technology 
base  ensures  a  greater  probability  of  wide  dissemination  of 
the  methodology  to  those  agencies  and  contractors  involved 
in  the  system  acquisition  process. 
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2 .  Competitive  Exploration  of  Alternative  Solutions 


DODD  5000.1  and  DODD  5000.2  state  that  after  a 
mission  need  has  been  established  and  approved  there  will  be 
a  competitive  exploration  of  alternate  solutions  to  the 
need.  Participation  in  this  exploration  is  open  to  industry, 
educational  institutions,  and  government  facilities. 

Though  industry  and  educational  institutions  are 
considered  to  be  the  primary  sources  of  solutions,  this  in 
no  way  should  lessen  the  contribution  that  government 
laboratories  and  facilities  can  make  through  use  of  an  RSL 
methodology  and  a  corporate  history  of  lessons  learned. 

A  hypothetical  case  might  be  the  total  replacement 
of  the  Naval  Tactical  Data  System  ( NTDS )  during  the  1990 's 
due  to  system  obsolescence.  By  this  time  there  will  have 
been  a  large  database  built  concerning  the  performance 
problems,  acquired  from  user  reports  in  the  past  and  from 
the  evaluative  study  required  to  establish  the  mission  need 
of  a  replacement  system, 

A  methodology  such  as  SREM  might  prove  beneficial  to 
an  on-going,  evaluative  study  as  it  enables  personnel  to 
determine  the  effect  of  additional  or  modified  requirements 
on  a  system  such  as  NTDS.  The  lack  of  an  expeditious  and 
efficient  handling  of  any  new  threat  or  threat  scenario  by 
the  system  could  be  determined  as  far  as  the  present 
hardware  and  software  configuration  is  concerned.  These 
findings,  coupled  with  the  known  problems  in  the  development 
of  the  old  system,  serve  as  a  solid  foundation  for  the 
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Bequest  for  Proposals  (RFP)  that  is  sent  to  interested 
contractors,  soliciting  alternate  solutions. 

The  RFP  cannot  presuppose  system  design  hut  it 
should  accurately  reflect  the  user's  requirements  of  the 
system.  The  contractors'  proposals  can  he  no  better  than  the 
RFP  on  which  they  are  based. 

The  government  laboratory  that  undertakes  the 
development  of  an  alternate  solution  to  the  mission  need 
should  first  of  all  be  totally  divorced  from  the  group  that 
developed  the  RFP  so  as  to  preclude  the  possibility  of  a 
prejudicial  view  of  the  system,  which  may  stifle  the 
creativity  of  the  system  designers,  and  also  to  ensure  fair 
competition  among  the  various  parties  involved. 

The  government  facility  may  have  an  advantage  in 
that  it  should  have  a  better  opportunity  to  evaluate  the 
operational  environment  in  which  the  system  will  be 
deployed.  Since  in  the  case  of  NTDS  the  government  facility 
would  in  all  likelihood  be  a  Navy  command,  the  personnel 
involved  should  have  among  them  those  who  fully  understand 
the  functions  of  the  Combat  Information  Center  (CIC)  in  a 
wartime  environment.  This  alone  should  improve  the  human 
engineering  aspect  of  the  system  design,  a  facet  too  often 
overlooked  or  misunderstood,  especially  in  the  stressful 
situation  of  actual  combat.  Not  only  is  a  system  that  works 
critical,  but  also  a  system  that  can  be  effectively 
interfaced  by  personnel  of  various  ranks,  educational  and 
experience  levels.  An  RSL  methodology  can  enable  the 
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as  the  sytem 


designers  to  take  this  into  consideration 
design  develops  since  all  inputs,  outputs,  ar.d  human 
interfaces  become  highly  visible. 

C.  DEPARTMENT  OE  DEFENSE  DIRECTIVE  5000.29 

DODD  5000.29,  "Management  of  Computer  Resources  in  Major 
Defense  Systems"  [22],  addresses  the  problem  of  management 
and  control  of  computer  resources  during  the  development, 
acquisition,  deployment,  and  support  of  major  defense 
systems . 

This  directive  has  a  significant  impact  on  software.  It 
mandates  that  the  software  design  (specifications)  be 
validated  (demonstrated  that  it  satisfies  all  current  stated 
requirements  of  the  system)  during  the  Concept  Formulation 
and  Program  Validation  phases  of  system  development,  prior 
to  the  Defense  Systems  Acquisition  Review  Council  (DSARC ) 
II.  (DSARC  II  rules  on  whether  or  not  to  permit  full-scale 
engineering  development  of  a  proposed  system). 

Other  points  emphasized  are  that  correctness  of 
software,  reliability,  integrity,  main tainabi li ty ,  ease  of 
modification,  and  transf errability  are  major  considerations 
in  the  initial  design. 

The  above  paragraph  contains  what  must  still  be 
considered  moot  points:  these  requirements  have  yet  to  be 
defined  in  a  manner  by  which  a  universally  accepted  criteria 
for  evaluation  of  these  requirements  can  be  established. 
However,  the  validation  requirement  should  serve  to  force 
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the  Issue  of  requirement  and  specification  visibility.  A 
methodology  such  as  SREM  can  Prable  the  contractor  to 
accurately  validate  his  specifications  against  the  stated 
requirements  and  verify  that  his  system,  as  far  as  the 
specifications  are  concerned,  will  function  properly. 

The  cognizant  naval  agency  could  also  use  SREM  to 
validate  the  contractor's  specif ica ti cn .  This,  however,  may 
prove  troublesome  if  the  specifications  are  not  written  in 
RSL  format  as  there  may  not  be  an  accurate  translation  of 
the  specifications  from  narrative  form  to  RSL  form. 

The  criticality  of  the  validation  process  cannot  be 
overemphasized.  It  is  the  last  point  in  the  acquisition 
process  in  which  major  changes  can  easily  be  implemented 
into  the  system  design.  Once  full-scale  engineering 
development  is  initiated,  the  Navy  effectively  reduces  its 
design  control.  Therefore,  the  use  of  an  RSL  methodology  can 
help  ensure  proper  validation  of  system  design. 

E.  DEPARTMENT  OF  DEFENSE  INSTRUCTION  5010.21 

DODD  5010.21  [23]  is  entitled  "Configuration  Management 
Implementation  Guidance".  Configuration  management  is  a 
discipline  applying  technical  and  administrative  direction 
and  surveillance  to  (1)  identify  and  document  the  functional 
and  physical  characteristics  of  a  configuration  item 
(hardware/software  that  satisfies  an  end  use  function),  (2) 
control  changes  to  those  characteristics,  and  (3)  record  and 
report  change  processing  and  implementation  status. 


As  previously  discussed,  both  SPEM  and  PSL/PSA  can 
perform  certain  configuration  management  tasks,  including 
"locking-in ’’  selected  portions  of  the  design  to  prevent 
further  change,  and  they  will  also  generate  reports  as  to 
changes  made  to  the  database. 

E.  MILITARY  STANDARD  1679  (NAVY) 

Military  Standard  (MIL-STD )  1679  (NAVY),  "Weapon  System 
Software  Development",  [24]  was  developed  to  reflect  the 
need  to  have  more  stringent  control  in  the  development  of 
software  for  weapons  systems.  The  main  reasons  for  this  were 
the  criticality  of  performance  inherent  in  such  systems,  a 
changing  operational  environment  necessitating  changes  to 
the  system,  and  the  high  life  cycle  cost. 

Appendix  A  contains  Chapter  5  of  this  MIL-STD  entitled, 
"Detailed  Requirements".  Because  of  their  capabilites 
discussed  in  previous  chapters,  it  is  felt  that  systems  such 
as  SREM  and  PSL/PSA  directly  aid  the  contractor  in  meeting 
the  requirements  imposed  by  the  following  sections  of 
Chapter  5: 


5. 1.2.5. b 

Block  Diagrams 

5. 1.2. 5. d 

Function  Description 

5. 1.2. 6 

Detailed  Functional  Requirements 

5 . 2 . 2  .3 

Program  Functional  Flow 

5.4.2 

Naming 

5.4.4 

Narrative  Description 

4 
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? .  5 


5. 5.6.2 


5. 9. 1.4 
5.11 

5.11.1.2 


Program  Production 
Cross-ref erenc®  Listing 
Program  Design 
Configuration  Management 
Documentation  Identification 


There  are,  however,  two  sections  which  should  he 
considered  for  modification  so  as  to  better  utilize  a  system 
such  as  SREM. 

The  first  is  section  5.2,  "Program  design  requirements". 
Chapter  IV  included  a  discussion  of  the  problems  inherent 
with  the  traditional  functional  hierarchy  approach  to  the 
development  of  requirements.  SEEM  does  not  design  in  such  a 
manner,  it  utilizes  a  flow  orientation  to  the  problem.  This 
is  presently  not  compatible  with  the  above  section. 

The  second  is  section  5.4.5,  "Flow  charts".  SREM  has  the 
capability  of  producing  detailed  functional-flow  diagrams. 
These  diagrams  can  give  a  clear,  concise  view  of  the 
system's  operation  and  the  interrelationship  of  the  various 
functions?  a  very  valuable  visual  aid.  If  a  system  is  indeed 
developed  utilizing  SREM,  functional-flow  diagrams  should  be 
considered  a  deliverable  item. 


F.  SPECIFICATION  AND  DOCUMENTATION  STANDARDS 

Perhaps  the  greatest  conflict  between  RSL  systems  and 
the  requirements  imposed  in  the  systems  acquisition  process 
is  in  the  area  of  specification  and  documentation.  One  of 
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the  problems  discussed  in  Chapter  VI  was  that  RSL  generated 
specifications  do  not  easily  map  into  the  structure  and 
format  required  by  OPNAVINST  3560.1,  "Department  of  the  Navy 
Tactical  Digital  Systems  Documentation  Standards"  [25].  The 
same  holds  true  for  Military  Standard  490,  "Specification 
Practices"  [26] . 

Appendix  3  contains  an  excerpt  from  MIL-STD  490  which 
deals  with  specif i ca tl ons  applicable  to  development  of 
computer  programs. 

Figure  8  lists  the  required  inputs  for  a  hypothetical 
engine  monitoring  system.  Figure  9  lists  the  required 
processing  flows  for  the  same  system.  Both  of  these  were 
produced  by  SREM  and  should  be  compared  to  sections  60.3.2.1 
and  60.3.2.2  in  Appendix  B  respectively.  It  is  evident  that 
RSI  generated  specifications  are  of  a  highly  structured 
nature,  whereas  MIL-STD  490  is  narrative  dependent. 


The 

chief  complaint  expressed 

by 

RSL  users 

to 

wards 

standards  such  as  MIL-STD 

490  is 

th 

at  such  a 

sta 

ndard 

imposes 

such  a  strict  format 

that 

the 

structure 

of 

the 

system 

is  lost,  especially 

since 

a 

system  such 

as 

SREM 

structures  it  designs  uniquely. 

For  now,  the  above  complaint  should  be  considered  one  of 
a  highly  subjective  nature.  Some  users  have  at  their 
disposal  a  translator  which  transforms  specifications  of  the 
form  given  in  Figures  8  and  9  into  the  form  required  by 
MIL-STD  490,  including  narrative,  with  some  degree  of 
success.  It  will  take  both  further  use  and  refinements  of 


68 


SUBSYSTEM:  ENGINE-MULTIPLEXER 
CONNECTED  TO 

INPUT-INTERFACE:  MUX-INPUT 

PASSES 

MESSAGE:  ENGINE-MEASUREMENTS 
MADE  EY 

DATA:  MEASUREMENTS 
INCLUDES 

DATA:  SENSOR-DATA 

INCLUDES 

DATA:  MEASURED-PI 
DATA:  MEASURED-P2 

DATA:  MEASURED-P3 
DATA:  MEASURED-P4 
DATA:  MEASURED-T1 
DATA:  MEASURED-T2 
DATA:  SWITCH-DATA 
INCLUDES 

DATA:  MEASURED-SI 
DATA:  MEASURED-S2 

SUBSYSTEM:  ENGINEERING-STATION 
CONNECTED  TO 

INPUT-INTERFACE:  FROM-ENGINEER 
PASSES 

MESSAGE:  ENGINE-SET-UP 
MADE  EY 

FILE:  SET-UP-LIST 
CONTAINS 

DATA:  SET-UP-DATA 

INCLUDES 

DATA:  NEW-PARAMETERS 
DATA:  NEW-VALUE 

MADE  BY 

DATA:  COMMAND-TYPE 
DATA:  ENG-NO 
MESSAGE:  HISTORY-REQUEST 
MADE  BY 

DATA:  COMMAND-TYPE 


Figure  8. 
Required  Inputs 


-MET :  PROCESS-ENGINE-DATA 

•STPITP  THBIP  • 

INPUT-INTERFACE:  MUX-INPUT 
VALIDATION-POINT:  VP-1 
ALPHA:  VALIDATE-MES  SAGE 
CONSIDER  DATA:  DATA-VALIDITY 
IF  (VALID) 

SELECT  ENTITY -CLASS:  ENGINE  SUCH  THAT 
(CHANNEL-NUM  =  MONITOR-CHANNEL-NO) 

DO 

ALPHA:  UPDATE-HISTORY-FILE 
TERMINATE 

AND 

ALPHA:  COMPARE-TO-LIMITS 

CONSIDER  DATA:  MEASUREMENT-STATUS 
IF  (ALARM-STATE) 

ALPHA:  TRANSMIT-ALAR^ 
VALIDATION-POINT:  VP-3 
OUTPUT-INTERFACE:  TO-ENGINEER 
OR  (WARNING-STATE) 

ALPHA:  TRANSMIT-WARNING 

VALIDATION-POINT:  VP-4 
OUTPUT-INTERFACE:  TO-ENGINEER 
OR  (NORMAL) 

TERMINATE 

END 


Figure  9. 

Required  Processing 


the  translators  to  Instill  confidence  in  the  translaed 
requirements . 

C-.  SUMMARY 

The  above  sections  are  by  no  means  a  comprehensive 
review  of  the  documents  discussed,  nor  do  they  review 
all  documents  governing  system  acquisition.  However,  the 
above  discussion  points  out  the  fact  that  RSL  systems, 
for  the  most  part,  can  be  made  to  support  the  current 
system  acquisition  process,  if  the  incompatibilities  of 
RSL  with  existing  military  specifications  and  standards 
can  be  resolved. 
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VIII.  RECOMMENDATIONS 


A.  INTRODUCTION 

The  Navy  Is  in  need  of  increasing  its  activities  in  the 
requirements  definition  area.  DOD  has  provided  development 
funds  to  the  Air  Force  for  URL/URA  (a  derivative  of  PSL/PSA) 
and  to  the  Army  for  SREM  [2?].  The  Navy  currently  has  no 
development  projects  of  this  nature. 

The  research  conducted  hy  the  other  services  may  he  of 
benefit  to  the  Navy,  but  there  is  no  guarantee  of 
universality  in  its  application.  Due  to  differences  in 
weapon  systems  requirements  and  overall  management 
philosophies,  it  is  highly  unlikely  that  inter-service 
transfer  of  technology  could  occur  without  undue 
modification.  One  Navy  user  of  URL/URA  found  it 
unsatisfactory  for  Navy  applications.  As  subjective  as  this 
opinion  may  be,  it  points  out  the  fact  that,  much  like 
aircraft,  it  is  nearly  impossible  to  satisfy  two  services 
with  a  single  system. 

The  Navy  needs  to  take  corrective  action  to 
systematically  improve  its  procedures  for  the  development  of 
software.  The  first  step  recommended  is  to  hold  a  major 
conference  with  all  facilities  within  the  Navy  involved  in 
software/system  design,  including  project  offices, 


represented.  Some  of  the  area  that  should  he  dealt  with  are 
discussed  in  the  following  sections. 

B.  PROBLEM  IDENTIFICATION 

It  is  quite  important  to  initially  identify  all  problems 
that  currently  exist  in  the  development  of  requirement 
specif icati ons  and  the  application  of  automated 
tools/methodologies.  Those  problems  cited  in  Chapter  VI  are 
only  a  small  fraction  of  the  those  existent  today.  Through 
their  proper  identification,  a  strategy  can  be  evolved  to 
develop  solutions. 

C.  AUTOMATED  TOOI  AND  METHODOLOGY  EVALUATION 

At  present,  there  has  been  no  comprehensive,  comparative 
study  of  the  major  automated  tools  and  methodologies  that 
currently  exist  in  this  field.  Initiation  of  such  a  study 
should  seriously  be  considered  by  the  Navy. 

The  study  should  be  initiated  under  the  premise  that  no 
one  tool  or  methodology  will  entirely  satisfy  the  needs  of 
all  projects.  Real-time  combat  systems  and  ADP  systems  are 
almost  totally  divergent  in  their  system  requirements. 
Though  current  experience  shows  that,  at  a  minimum,  a 
disciplined  methodology  of  some  form  is  required  throughout 
the  entire  spectrum  of  software-related  projects,  it  is  a 
question  of  applying  a  particular  methodology  or  automated 
tool  where  it  will  give  the  greatest  return  in  terms  of 


improved  definition  of  requirements  specifications. 
Acceptance  of  any  new  technology  comes  mainly  through 
demonstration  of  superior  results. 

The  tools  and  methodologies  chosen  for  application  in  a 
particular  area  should  meet  known  requirements,  have  a 
capacity  for  evolutionary  growth,  and  have  a  reasonably  long 
expected  lifetime.  Above  all,  it  must  be  understandable  and 
suitable  for  training  [28].  The  fact  that  tools  and 
methodologies  developed  by  highly  trained,  highly  educated 
personnel  do  not  guarantee  successful  application  by 
personnel  of  varying  backgrounds  should  cot  be  overlooked. 
The  members  of  the  evaluation  group  must  reflect  this 
diversity. 

D.  ACCEPTANCE  AND  TRAINING 

Some  of  the  reasons  stated  by  Wolverton  [28l  for 
personnel  not  using  tools  in  general  are  that  they  see  no 
benefit  to  them,  lack  of  understanding  of  the  tool, 
perceived  high  risk  of  failure,  management  coercion,  and 
lack  of  time  to  experiment  with  the  tool  due  to  schedule 
pressures . 

The  first  step  in  gaining  acceptance  of  a  tool  or 
methodology  is  in  total  management  support.  Though 
management  obviously  cannot  issue  an  edict  mandating  its 
Immediate  use  with  the  expectation  of  immediate  results,  it 
can,  nonetheless,  provide  firm  guidance  in  its  assimilation 
into  the  overall  design  process. 
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The  training  of  the  ultimate  end-users  should  not  only 
provide  a  thorough  understanding  of  the  tool  or  methodology, 
hut  should  also  he  directed  towards  instilling  confidence  in 
the  user  as  to  his  or  her  ability  to  use  the  tool  or 
methodology . 

Time  is  rarely  in  the  favor  of  any  project;  therefore, 
the  initial  use  of  such  a  tool  or  methodology  should  he  on  a 
project  which  does  not  have  great  pressures  of  time  and 
money.  Through  a  systematic  introduction,  the  tool  or 
methodology  will  be  afforded  a  better  chance  to  succeed  or 
fail  on  its  own  merits,  not  the  perceptions  of  the  users. 

E.  OTHER  CONSIDERATIONS 

The  adoption  of  a  tool  or  methodology  for  application  in 
a  particular  area  will  certainly  raise  a  myriad  of  questions 
that  cannot  he  dealt  with  in  this  thesis,  hut  as  an  example, 
take  the  hypothetical  case  SREM  is  adopted  as  the 
standard  automated  tool  for  weapon  sytems  software 
development.  Should  this  standard  he  imposed  on  contractors 
who  wish  to  hid  on  future  contracts  in  this  area?  If  not, 
should  the  Navy  train  personnel  in  the  various  techniques 
used  in  Industry  so  as  to  facilitate  the  liason  between 
project  office  and  contractor?  Can  the  documentation  and 
specification  standards  he  modified  so  as  to  allow  RSL 
generated  specifications  to  be  submitted  in  their  structured 
form?  These  and  other  questions  may  have  to  be  dealt  with  as 
the  state  of  the  art  in  software  technology  advances. 


IX.  CONCLUS IONS 


This  thesis  has  discussed  some  of  the  problems  inherent 
in  requirements  specifications  as  they  currently  are 
developed  and  has  looked  at  an  evolving,  disciplined 
approach  to  the  problem  in  the  form  of  requirement  statement 
languages  and  systems.  The  promising,  if  not  proven, 
automated  tools  utilizing  requirement  statement  languages, 
SREM  and  PSI/PSA,  have  been  shown  to  have  capabilities  that 
ray  prove  to  be  of  great  value  in  systems  acquisition.  They 
have  also  been  shown  to  have  some  drawbacks  as  well. 

Also  discussed  in  this  thesis  are  some  suggestions  as  to 
how  the  Navy  should  approach  this  technology,  such  as 
evaluation  of  these  and  other  tools  and  methodologies,  their 
incorporation  into  projects  where  the  benefit  would  be 
greatest,  and  gaining  the  acceptance  of  those  who  would 
actually  be  required  to  use  such  systems. 

Above  all,  this  thesis  has  stressed  that  these  types  of 
tools  and  methodologies  need  to  be  seriously  considered  by 
the  Navy  as  a  possible  solution  to  some  of  its  problems  in 
systems  acquisition. 
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APPENDIX  A  -  MILITARY  STANDARD  1679 


•  • 


3.1  Program  performance  requirements.  The  contractor  shall  determine 
Che  detailed  program  performance  requirements  for  the  weapon  system  soft¬ 
ware.  The  contractor  shall  utilise  the  basic  descriptive  requirements  and 
design  information  provided  by  Che  procuring  agency  to  create  the  program 
performance  requirements.  This  Information  may  he  augmented  by  studies, 
analysis,  visits  to  operational  units,  and  surveys  as  necessary.  The 
program  performance  requirements  are  subject  to  Che  approval  of  the  pro¬ 
curing  agent. 

3.1.1  Supporting  information.  The  contractor  shall  utilise,  as  a  minimum, 
chat  of  che  following  supporting  information  which  is  available  to  deter¬ 
mine  the  program  performance  requirements: 

a.  System-level  performance  requirements. 

b.  System-level  design  specif lcatlons. 

C.  Equipment  design  specifications. 

d.  Interface  design  specifications. 

e.  Operational  standards,  doctrine  and  tactics. 

t.  System  design  standards. 

3.1.2  Analysis.  In  determining  che  performance  requirements,  che  contractor 
shall  investigate  and  analyze  in  detail  all  areas  relating  to  the  perform¬ 
ance  requirements  of  che  weapon  system  software. 
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3. 1.2.1  Mission  areas.  Th«  concrsceor  shall  investigate  th«  mission  areas, 
priaary  and  secondary,  and  supporting  casks  of  ehs  operational  user  or 
platform  for  the  weapon  syscea. 

3. 1.2. 2  Functions.  The  contractor  shall  define  the  major  functions  or 
(roupings  of  the  program  necessary  to  meet  the  system  performance  require¬ 
ments. 

3. 1.2. 3  Applicable  documentation.  The  contractor  shall  Identify  all  docu¬ 
ments  which  define  or  constrain  the  program  performance  requirements. 
Definitions  of  applicable  ceras  and  abbreviations  not  consistent  with  or  not 
included  in  reference  document  2.1.c  shall  be  indicated  and  defined  by 

the  contractor. 

3. 1.2. A  Weapon  system  description.  The  contractor  shall  examine  the 
relationship  of  all  components  in  the  weapon  system  which  affect  the  program 
performance  requirements  or  the  computer  program.  He  shall  determine  how 
the  computer  program  interfaces  with  ocher  components  to  perform  required 
functions. 

e.  Peripheral  equipment  identification.  The  contractor  shall  identify 
all  equipment  with  which  the  program  will  interface. 

b.  Interface  identification.  The  contractor  shall  identify  all  ocher 
digital  programs  or  systems  with  which  the  program  will  interface. 


.  J 
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3.1. 2.5  functional  description.  The  contractor  shall  analyze  the  major 
functions  and  the  functional  relationships  of  the  program  with  interfacing 
equipments  and  other  programs. 

« 

a.  Equipment  descriptions.  The  contractor  shall  identify  the  require¬ 
ments  imposed  on  the  program  by  each  interfacing  equipment,  the 
purpose  cf  the  equipment,  and  the  use  of  options  and  controls. 

b.  Block  diagrams.  The  contractor  shall  generate  diagrams  of  equip¬ 
ment/program  relationships  with  internal  and  external  data  flow. 

e.  Inccrsystem  Interface.  The  contractor  shall  determine  the  inter¬ 
faces  with  ocher  systems  and  shall  be  cognizant  of  the  performance 
requirements  and  design  specifications  of  all  systems  which  will 
interface  with  the  system  under  development.  Each  contractor  shall 
be  aware  of  the  purpose  of  the  interface  and  the  data  to  be  exchanged. 
Data  quantity,  frequency,  rate,  format,  content,  scaling  requirements 

e 

and  conventions  shall  be  developed.  In  fulfilling  this  assignment, 
the  contractor  may  be  tasked  to  participate  with  ocher  development 
contractors  as  a  team  to  design  the  inter-system  interfaces  so  that 
the  performance  requirements  of  all  systems  arc  met.  'Cf  Interface 
Conflicts  are  uncovered  such  chat  an  individual  system’s  ability 
to  perform  in  accordance  with  its  requirements  is  adversely  affected, 
the  Interface  design  team  shall  recommend  to  the  procuring  agency  the 
N  necessary  modifications  to  the  systems  or  their  interface  to  overcome 
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th«  deficiency.  If  no  solution  can  be  agreed  upon,  the  c earn  shall 
recommend  modlficadon  of  Che  system  performance  requirements  Co 
the  procuring  agent. 

d.  function  description.  The  contractor  shall  establish  the  performance 
of  each  function  supported  by  the  program,  its  purpose,  and 
1 use Clonal  design. 

3. 1.2. 6  l’etalled  functional  requirement.  The  contractor  shall  delineate  the 
performance  of  each  function  by  detailing  its  narrative,  logical,  and  mathe¬ 
matical  descriptions. 

a.  inputs.  The  contractor  shall  define  all  inputs  (external  and 
internal)  including  their  sources,  sethod  of  insertion,  quantity, 
timing,  range  and  sealing. 

b.  Processing.  The  contractor  shall  generate  textual  and,  as  appropriate, 
mathematical  descriptions  of  the  processing  requirements  of  each 
function,  including  functional  parameters  and  geometric  diagrams. 

c«  Outputs.  The  contractor  shall  define  all  outputs  (Internal  and 
external)  including  their  method  and  timing,  meaning,  format, 

.  destinations,  range  and  scaling. 

4.  Special  requirements.  The  contractor  shall  identify  all  require¬ 
ments  imposed  by  higher- level  constraints  or  by  exigencies  of  the 
function. 


3.1. 2. 7  Adaptive  parameters.  The  centractor  shall  identify  those  parameters 
which  reflect  the  system  environment,  system  parameters,  and  system  capa¬ 
cities,  and  which  can  be  modified  without  altering  the  logic  of  the 
operational  function. 

3,1.3  System  resources.  The  contractor  shall  define  the  computer  memory, 
computer  processing  time  and  input  and  output  resource  budgets  and  the 
projected  utilization  for  the  weapon  system.  If  tie  weapon  system  under 
development  has  more  than  one  digital  processor,  cfe  contractor  shall 
define  these  resource  values  for  each  digital  processor. 

3.2  Program  design  requirements .  The  computer  prof ram  design  shall  be 
developed  from  the  program  performance  specification,  and  shall  comply 
with  other  design  constraints  and  standards  as  specified  by  the  procuring 
agency.  The  software  development  shall  be  a  top-down  process.  The  design 
•hall  be  a  hierarchical  structure  of  identifiable  programs,  subprograms, 
modules,  procedures  and  routines.  The  highest  level  of  control  logic  resides 
at  the  top  of  the  hierarchy;  the  computational  or  algorithmic  functions 
reside  at  the  Lower  levels.  The  contractor  shall  define  the  assumptions, 

Che  programming  approach  for  implementing  Che  computer  program  and  shall 
define  the  program  architecture.  Tha  program  design  shall  be  subject  to 
review  by  the  procuring  agency. 

3.2.1  Supporting  information.  The  contractor  shall  utilize,  as  a  minimum, 
that  of  the  following  supporting  information  which  is  available  to  determine 
the  program  design: 


a.  System  operational  design  documents. 

b.  Program  performance  specification. 

e.  Interface  design  specifications. 

4.  Trograaalng  reference  manuals, 
a.  Equipment  technical  manuals. 

f.  Specified  programming  standards  and  conventions. 

g.  Specified  utilicy/support  software. 

5.2.2  Computer  program  design  analysis.  In  determining  the  detailed  com¬ 
puter  program  design,  the  contractor  shall  Investigate  and  analyze  in  detail 
tha  following  areas  relating  to  the  computer  program. 

3. 2. 2.1  Applicable  documentation.  All  documents  which  constrain,  define,  or 
Influence  the  program  design  shall  be  analyzed.  The  contractor  shall  define 
all  design  terms  and  abbreviations  used  to  describe  the  program  design. 

3. 2. 2. 2  functional  allocation.  The  allocation  of  functions  and  tasks  to 

be  performed  by  the  subprograms  and  a  functional  description  of  Items, 
inputs,  outputs,  and  processing  to  be  performed  shall  be  considered  end 
subsequently  defined.  All  performance  requirements  shall  be  satisfied  In 
their  entirety  in  thle  a _ icatlon. 

3. 2. 2. 3  teaource  allocation  and  reserves.  Memory  storage  end  processing 
time  for  each  subprogram  shall  be  determined.  Total  system  memory  end 
processing  time  reserves  of  at  least  20  percent  shall  exist  at  the  time  of 
program  acceptance  by  the  procuring  agency. 


3. 2. 2. 4  Program  functional  flow.  The  flow  of  program  data  and  control  In 


all  required  modes  of  program  operaclon  shall  be  determined. 

a.  Program  interrupt  eonerol.  The  source,  purpose,  type,  predicted 
race  of  occurrence,  and  required  control  response  for  each  ex¬ 
ternal  and  Internal  Interrupt  shall  be  determined  from  the  analysis. 

b.  Subprogram  reference  control.  The  control  Logic,  assignment  of 
priorities,  and  permissible  cycle  times  for  each  subprogram  shall 
be  deterulned  from  the  analysis. 

c.  Special  control  features.  Unique  control  requirements  which  affect 
tha  deal, in  of  the  control  logic  shall  be  identified. 

3. 2. 2. 3  Design  constraints.  The  constraints  of  the  specific  programming 
language  to  be  used;  the  constraints  of  the  specific  compiler,  monitor, 
loader,  librarian  to  be  used;  tha  capabilities  of  specific  debug  and  utility 
aids  for  tha  program  production;  and  tha  mnemonic  labeling  conventions  re¬ 
quired  shall  ba  daflnad  by  tha  contractor. 

3. 2. 2. 6  Data  base  design.  All  data  usad  by  two  or  more  subprograms  shall 


ba  taken  into  account  during  tha  computer  program  design 


3.2.3  Intersyscea  Interface.  The  contractor  shall  determine  tha  intar- 
facaa  with  other  systems  and  shall  be  cognizant  of  the  performance  require¬ 
ments  and  design  specifications  of  all  systems  which  will  Interface 

with  the  system  under  development.  Each  contractor  shall  be  aware  of  the 
purpose  of  the  Interface  and  the  data  to  be  exchanged.  Data  quantity, 
frequency,  race,  format,  concent,  scaling  requirements  and  conventions 
shall  be  developed.  In  fulfilling  this  assignment,  tha  contractor  aay  be 
tasked  to  participate  with  ocher  developaent  contractors  as  a  team  to 
design  the  Inter-system  Interfaces  so  that  the  performance  requirements 
of  all  systems  are  met.  If  Interface  conflicts  are  uncovered  such  that 
an  individual  system's  ability  to  perform  in  accordance  with  Its  require¬ 
ments  Is  adversely  affected,  the  Interface  design  team  shall  recommend 
to  the  procuring  agency  the  necessary  mot  If icatlons  to  the  systems  or  their 
Interface  to  overcome  the  deficiency.  If  no  solution  can  be  agreed  upon, 
the  team  shall  recommend  modification  of  the  system  performance  require¬ 
ments  to  the  procuring  agent. 

.  \ 

3.3  Programming  standards.  The  following  coding  end  logic  standards  f  • 

shall  apply  to  tha  implementation  of  subprograms. 


3.3.1  Control  structures.  Program*  shall  h«  designed  using  only  the  five 
basic  control  structures  presented  In  figure  1.  They  are:  The  SEQUENCE 
of  operations  (assignment,  add,...),  IP  THEN  ELSE  (conditional  branch  to 
one  of  two  operations  and  return) ,  WHILE  DQ  (operation  repeated  while  a 
condition  Is  true) ,  DO  UNTIL  (operation  repeated  until  a  condition  Is 
true)  and  CASE  (operation  which  provides  the  transfer  of  program  control 
to  a  specific  locitlon  within  a  compile-time  system). 

3.3.2  Entry-exit  structure.  Each  module,  subprogram,  routine,  or  procedure 
shall  have  a  single  entry  and  single  exit  structure.  (See  figure  2.) 

3.3.3  Source  coda  segment  includes/copy.  When  repetitive 

segments  of  source  cod*  are  required  in  the  program  being  developed,  they 
shall  ba  coded  only  once  as  a  structural  source  cod*  block,  thereafter  being 
referenced/utilized  upon  each  occurrence  by  appropriate  INCLUDES  or  COPT 
features,  or  constructs  of  the  source  HOL  compiler.  These  Included/copled 
segments  shall  be  written  in  HOL  only.  Any  program  logic  within  a  given 
structural  segment  shall  utilize  only  those  control  structures  specified  in 
paragraph  3.3.1.  Por  maximum  memory  efficiency,  common  routines  or  pro¬ 
cedures  should  be  used  instead  of  included/copled  source  code  blocks 
whenever  practicable. 

\ 
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figure  LA. 


SEQUENCE . 


(W>  A 


EXIT 


3 


Control  flows  from  process  A  to  the  next  is  sequence,  process  B. 


figure  IB. 

If  THEN  1XSE. 


The  flow  of  concrol  will  return  to  e  common  point  after  executing  either 
process  B  or  C.  A  predicates  the  conditional  execution.  If  control  Is  to 
skip  a  process  pending  the  condition  of  A,  then  the  flow  chart  can  be 
Modified  thusly:  (See  next  page) 


fZCtfU  1.  Control  Structures. 
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FIGURE  13.  (Coctinued) 


FIGURE  1C.  WHILE  DO. 


The  WHILE  00  structure  is  s  loop,  la  which  the  condition  A  is  evaluated. 

If  found  to  be  true,  thea  control  is  passed  to  process  3,  and  then  condition 
A  is  evaluated  again.  If  condition  A  is  false  then  control  is  passed  out  of 
■the  loop. 
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ncott  10.  DO  UNTIL 


The  DO  OVCIL  structure  is  similar  Co  Ch«  WHILE  DO  —  «xc*pc  Chat  eh*  cese 
of  conditLon  A  Is  p«rform*d  a  fear  process  B  lias  executed.  Thus  eh*  DO 
UNTIL  loop  will  b*  performed  one*  regardless  of  eh*  value  of  condielon  A. 


nanus  IE 

CASE. 


Conerol  is  passed  eo  process  'E*  based  on  eh*  value  of  1.  Scruccured 
programs  of  any  degree  of  complexity  can  be  builc  up,  If  ehey  can  be 
broken  down  lnco  Individual  components. 
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3.3.4  Program  traceability.  Program*  shall  b«  designed  and  constructed 
such  Char  upon  Interrupt  or  termination,  the  values  of  the  various  para¬ 
meters,  indices,  and  other  local  variables  as  of  the  last  usage  are  recover¬ 
able. 

3.3.3  Self-modification.  Program  self-modification  of  instructions  during 
execution  shall  be  prohibited. 

3.3.6  Recursive  programs.  Recursive  procedures  or  programs  shall  not  be 
used  unless  the  target  computer  has  a  stack  orienced  architecture. 

3.3.7  Size.  The  procedures  or  routines  which  make  up  a  module  or  sub¬ 
program  shall  not  exceed  an  average  of  fifty  executable  HOL  statements  per 
procedure  or  routine.  Each  Independently  executable  HOL  statement,  whether 
free-standing  or  included  within  a  complex  statement,  counts  as  one  of  the 

fifer- 

3.3.5  Branching.  Branching  statements  (GO  TO's)  are  to  be  avoided  if 
possible,  and  used  only  with  tbo  approval  of  the  procuring  agency.  Branching 
statements,  if  approved,  shall  only  pass  control  to  a  statement  that  is  in 
the  seme  procedure  or  routine.  Each  GO  TO  must  pass  control  only  forward  of 
Its  point  of  occurrence.  Backward  Jumps  generated  by  the  compiler  are  per¬ 
mitted.  Transfers  from  a  procedure  or  routine  shall  only  be  to  the  entry 
point  of  another  procedure  or  routlno. 

3.3.9  Kalocacebllltv.  The  software  shall  be  built  In  the  form  of  relo¬ 
catable  object  modules. 


3.4  Programing  convene Ions.  The  following  pcograsalng  conventions  shall 
be  utilized  In  all  weapon  sysces  software. 

5.4.1  Symbolic  parameterization.  411  values  used  In  the  weapon  system  soft¬ 
ware  which  are  constant  throughout  the  weapon  system  design  but  which  may  be 
affected  by  environment  changes  (e.g.,  sensor  output  limits,  maximum  range 
ef  weapons,  maxiirum  number  of  targets  handled,  data  storage  limits)  shall 

be  treated  as  symbolic  parameters  In  the  design.  Duplication  of  symbolic 
parameters  shall  be  minimized  through  use  of  common  source  of  values.  When 
duplication  Is  necessary,  common  symbolic  parameter  Identification  nomen¬ 
clature  shall  be  used  and  comments  will  point  to  location  of  duplicates. 

Symbolic  parameters  shall  be  grouped  ae  the  baginning  of  each  program.  Comments 
shall  provide  a  definition  and  the  location  of  all  parameters.  Special  symbolic 
parametric  definition  features  of  the  high  level  language  and  compiler  shall 
be  used. 

3.4.2  Hamlng.  Naming  conventions  shall  be  uniform  throughout  the  weapon 
system  software. 

3.4. 2.1  Modules .  Module  names  shall  be  uniquely  chosen  to  identify  the 
applicable  function  performed  and  the  hierarchical  logic  structure  In  relation 
ee  other  modules  in  the  system  being  developed. 

3.4. 2. 2  Decs.  Data  names  shall  Indicate  the  function  of  the  data  Item. 

5.4.3  Numerical  conventions.  Numerical  conventions  shall  ba  established 
by  the  contractor  so  chat  choy  aro  uniform  throughout  the  program. 
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3. 4. 3.1  Symbolic  constants  and  variable*.  Constance  and  variables  entering 
loeo  numerical  computations  shall  follow  the  constraints  set  forth  In  para¬ 
graph  5.4.1. 

5.4. 3.2  Mixed  node  expression.  Mixed-node  numerical  operations  shall  be 
avoided  whenever  possible,  but  when  determined  to  be  necessary,  they  shall 
be  completely  described  in  comments. 

5. 4. 3. 3  Grouping.  Parentheses  or  other  subexpression  delimiters  shall  be 
used  whirs  necessary  to  clarify  the  order  of  evaluation  of  compound  expres¬ 
sions. 


5.4. 3. 4  Significant  digits.  The  number  of  significant  digits-  as  output  shall 
not  be  greater  chan  the  number  of  significant  digits  as  input.  The  effect 

of  truncation  performed  shell  be  considered  in  applying  this  convention. 
Sufficient  significant  digits  shall  be  used  in  calculations  co  yield  a 
minimum  of  computational  error,  and  rounding  by  the  programmer  shall  not 
occur  until  the  final  computational  step.  The  degree  of  computational  error 
shall  be  analyzed  Co  determine  if  systems  accuracy  requirements  are  fulfilled. 

5.4.4  narrative  description.  A  narrative  description  shall  describe  tha 
history  and  ldantlfy  the  functions  of  proesdurss  and  routines. 

5.4. 4.1  Abstracts.  Each  procedure  and  rouclns  shall  ineluds  at  tha  beginning 
of  the  executable  coding  a  caxtual  description  of  its  inputs,  outputs, 
function  or  cask,  and  algorithms;  list  other  procedures  or  rouclnes  celled; 
and  list  all  calling  procedures  or  routlnss.  In  addition  eo  general 
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-explanations,  co  assist  understanding,  precise  references  to  the  appro¬ 
priate  scaten enc  labels  and  data-names  shall  be  Included  In  each  descriptive 
abstract.  Local,  previously  undefined  data-names  shall  be  described.  The 
•descriptive  abstract  shall  define  the  allowed  and  tolerable  range  of  values 
for  all  Inputs  aid  shall  define  the  allowed  and  expected  range  of  values 
for  all  outputs. 

5.4. 4. 2  Identlf '.cation.  Each  procedure  and  routine  shall  carry  an  identi¬ 
fying  label-name  indicating  function  and  hierarchical  structure.  A  history 
of  the  original  and  updating  prograancr  oases,  the  activity  or  commercial 

*  -company  name  and  the  activity  or  cospany  division  rode  or  billet  Identifier 
with  dates  completed  shall  be  included. 

5.4.4. 3  Statement  comments.  In  order  to  facilitate  program  comprehension, 
comment  statements  shall  be  used  throughout  the  program  code.  Comment 

«*  statements  are  non-executable  (i.e.,  those  which  have  no  effect  on  computer 
cperations)  ai-d  are  used  to  prorldn  documentation  and  clarification  of  the 

4  logic,  data,  variables,  sad  algorithms.  Each  source  statement  shall  be  self- 
defined  or  defined  by  a  comment  phrase  co  a  level  understandable  by  a  person 
mot  associated  with  Che  original  development  effort.  Logical  groups  of 
cm— enc  phrssss  may  bs  included  in  s  single  comment  statement.  General  com- 
.meats  on  groups  of  source  statements  performing  logical  functions  shall  ba 
included  on  separate  com ent  statements. 


'3*4.3  Source  record  format 


3.4. 5.1  Execution  efficiency.  Subject  only  to  the  Interest  of  readability, 
clarity  and  maintainability ,  source  statements  shall  be  coded  to  optimize 
object  code  execution. 

3.4. 3.2  Indentation.  Program  structural  Indentation  shall  be  used  to  Im¬ 
prove  readability  end  clarity. 

3. 4. 3. 3  Source  statement.  A  source  stateawnt  shall  not  be  compound  or 
complex  In  structure  except  as  necessary  to  support  the  control  structures 
defined  In  paragraph  3.3.1. 

3. 4. 3. 4  Sequence  numbering.  Each  source  record  shall  contain  a  sequence 
number  prior  to  delivery  as  a  configuration  Item.  Sequence  numbers  within 
a  procedure  or  routine  shall  be  In  sequentially  increasing  order  beginning 
with  and  differing  by  some  multiple  of  ten. 

3.4.6  Listings.  Listings  related  to  the  program  shall  aeec  the  standards 
specified  herein. 

5. 4. 6.1  Content.  For  acceptance  as  a  deliverable  configuration  Item,  the 
listing  of  a  compiled  program  shall  include  source  language  statements  and 
comments  with  resulting  object  machine  Instructions  interspersed  appro¬ 
priately  (together  with  actual  or  equivalent  assembler  statements,  if  avail¬ 
able).  Relative  location  of  Instructions  and  operands  shall  be  exhibited 
together  with  statement  labels,  Identification  numbers,  and  card  identifiers. 
All  descriptions  of  referenced  routines,  functions,  tables,  variables,  con¬ 
stants,  files,  indices,  etc.,  shall  be  Included  In  conjunction  with  this 
listing  and  arranged  for  convenient  access. 
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3. 4. 6. 2  Cross-reference  listing,  k  cross-reference  listing  shall  be  pro¬ 


duced  relating  each  data  name  to  the  address  of  every  other  statement  refer¬ 
ring  to  it,  and  relating  each  routine  and  the  address  of  ocher  routines 
calling  upon  it.  The  list  shall  be  exhibited  as  a  sequential  cable  in 
alphanumeric  order. 

5.4.7  Flow  charts.  There  is  no  requirement  that  flow  charts  be  a  deli¬ 
verable  item. 

3.5  Program  production.  The  contractor  shall  generate  the  program  in  an 
orderly  and  well-controlled  manner.  The  requirements  shall  be  translated 
Into  program  design  it.  a  systematic  top-down  method.  The  system  shall  be 
divided  into  constituent  parts  and  then  these  parts  broken  down  into  their 
constituents.  Each  level  of  design  development  Cor  break  down)  is  con¬ 
tinued  until  a  level  is  reached  wherein  no  other  function  is  subservient  to 
the  function.  Levels  shall  be  structured  so  chat  a  lower  level  function 
does  not  call  on  a  higher  level  function.  Program  coding  shall  follow  the 
same  structure  as  the  design,  which  allows  identifiable  division  of  the  pro¬ 
gramming  cask.  Programming  shall  commence  with  the  highest  levels  which  shall 
Chen  be  tested  extensively  and  placed  under  cotfiguraclon/llbrary  control 
before  descending  downward  in  the  design  to  the  programming  of  any  subordinate 
levels.  Efficient  and  effective  control  of  the  program  during  coding  and  test 
.1*  required. 

V 

5.5.1  Organization.  The  contractor  shall  implement  a  program  production 
organisation  that  facilitates  the  top-down  design,  coding,  and  test  of  the 


program, 


MICROCOPY  RESOLUTION  TEST  CHART 

NATIONAL  BUREAU  OF  STANDARDS  1963 -A 


\ 


3.3.2  Timing  and  mtnorv  management.  Ths  contractor  shall  b«  responsible 


foe  management  of  computer  system  resources  (e.g.,  main  memory,  mass 
Storage,  processor  time,  Input /output  eontroller(s) ,  and  lnput/output 
Channel (a)).  He  shall  determine  the  original  assignment  of  system  resources 
through  analysis  and  modeling.  The  contractor  shall  monitor  the  utilization 
of  the  assigned  resources  as  program  development  progresses.  A  minimum 
reserve  >f  20  percent  capacity  shall  exist  la  each  resource  area  at  the 
time  of  program  acceptance  by  the  procuring  agency. 

3.3.3  Library  usage  and  control.  The  contractor  shall  establish  procedures 
for  producing,  updating,  and  controlling  source  and  object  libraries  of 

the  softi'nrm  under  development.  All  initial  programs  and  development  changes 
shall  be  maintained  in  both  source  and  object  format.  All  program  patches 
shall  be  maintained  in  maintenance/ patch  legs  and  on  patch  tapes  until 
incorporated  in  the  patch-free  source  program.  Program  patches  shall,  as 
a  minimum,  be  identified  by:  patch  production  date,  programmer  producing  the 
patch,  the  program  segment  that  tht  patch  is  applicable  to,  the  corresponding 
problem  number  or  identification,  tha  taat  that  revealed  the  problem,  the 
testing  that  certifies  ths  integrity  of  the  patch  and  the  problem  that 

*  necessitated  the  patch. 

3.3.4  Load  mage.  The  contractor  shall  daaeriba  tha  format,  mathod  and 
location  in  vhieh  tha  various  portions  of  tha  program  ara  loadad  and  storad 
in  the  weapon  system  computers  and,  if  applicable,  disks  or  ocher  storage 

*  devices.  This  mapping  shall  include  delineating  all  of  tha  portions  of  tha 
program  chat  ara  to  ba  concurrently  resident  in  the  device  in  question  and 


Che  location  and  sir*  at  each  portion  of  eha  program.  If  eha  system  has 
■ora  than  ona  defined  configuration  or  mod*  of  oparation  for  eha  software, 
tha  contractor  shall  das cribc  this  information  for  each  configuration  or  mod*. 

3.6  Program  generation. 


5.6.1  Language.  Vaapon  system  software  shall  ba  coded  la  ona  of  eha  high 
ardor  programming  languages  (HOLs)  approved  by  eh*  Department  of  Defense 
uni ass  a  specific  waiver  has  bean  previously  granted  to  the  procuring  agency 
by  proper  authority. 


5.6.2  Program  regeneration.  All  weapon  system  software  delivered  by  the 
contractor  shall  b*  capable  of  being  regenerated  from  Government  owned  and 
the  delivered  support  software. 

• 

3.7  Program  operation.  The  contractor  shall  determine  the  procedures  for 
the  operation  of  tha  weapon  system  software.  Proce'sres  shall  be  described 
in  terms  undirstandabl*  to  operational  personnel .  Program  operation  procedures 
shall  he  subject  to  the  approval  of  tha  procuring  agoncy. 


6*7.1  Anal re la.  In  determining  program  operation  procedures,  tha  contractor 
shall  investigate  and  define  in  detail  tha  following  areaa. 

5.7. 1.1  Wow-functional  oparation.  Minimal  processor  snd  peripheral  equip¬ 
ment  requirements,  equipment  set-up  for  system  operation,  program  sat-up, 
special  paramater  entering  requirements,  standby/operate  procedures,  moni¬ 
toring  procedures,  and  racovery  procedures  shall  ba  defined. 
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3. 7. 1.2  Functional  operation.  Individual  operator  and  station  functions; 
eoordinatsd  station  procedures;  all  human  factor  aspects,  nodes  and  pro¬ 
cedures  necessary  for  each  console  or  station  operator  to  perform  his 
function  in  support  of  syseea  operation;  the  function  of  every  control 
button,  switch,  readout  and  display  affected  by  or  affecting  the  system; 
all  constraints  imposed  on  operator  actions  shall  be  defined. 

3.3  Quality  assurance.  The  contractor  shall  implement  quality  assurance 
procedures  to  verify  in  each  stage  of  the  development  that  the  product 
program  will  meet  the  current  performance  specifications  approved  by  the 
procuring  agency.  The  contractor  shall  Implement  quality  assurance  pro¬ 
cedures  ta  validate  the  accuracy,  correctness  and  performance  of  the 
product  programs,  to  verify  Che  accuracy  ant'  conformance  of  program  documen¬ 
tation  to  the  requirements  of  this  Military  Standard  and  to  ensure  that  all 
procedures  incumbent  on  the  development  activity  are  properly  and  completely 
followed.  The  procedures  shall  be  open  to  review  by  the  procuring  agency 
or  its  authorised  representative.  The  implementation  and  functioning  of 
the  procedures  shall  also  be  open  to  inspection  by  the  procuring  agency  or  its 
authorised  representative. 

3.3.1  Organisation.  The  quality  assurance  organisation  shall  include 
provisions  for  addressing  all  the  following  faeecs  of  quality  assurance. 

3.3.1. 1  Keporting  level.  The  contractor's  quality  assurance  organisation 
shall  have  a  corporate  reporting  responsibility  external  to  the  developing/ 

,  engineering  group  to  assure  an  objective  evaluation  of  conformity  and  progress. 


$•8.1.2  Participation  In  audits.  Th«  contractor's  quality  assurance  organi¬ 


sation  shall  present  and  shall  conform  with  procedures  for  independent 
quality  audits  that  should  cake  place  throughout  the  development  phase 
a Carting  with  design  development  and  ending  with  test,  certification, 
delivery  and  acceptanca  which  measure  system  conformance  with  technical  and 
management  requit ements  and  standards. 

3. 8. 1.3  Design  -aviews.  The  contractor's  quality  assurance  organization 
shall  participate  in  design  reviews  and  walk  throughs  utilizing  procedures 
to  assure  complt:«.enasa  and  accuracy  of  presented  materials  and  to  assure 
timely  and  correct  completion  of  action  assignments. 

3.8. 1.4  Testa.  'Ac  contractor's  quality  assurance  organization  shall  witness 
tests  to  assure  conformance  with  approved  procedures.  Quality  assurance 
activities  shall  include  record-keeping,  maintenance,  control  of  test  materials, 
and  conflict/discrepancy  resolution. 

5.8. 1.3  Deliverable  items.  The  contractor's  quality  assurance  organization 
shall  provide  and  shall  conform  to  procedures  to  assure  contractual  correctness 
of  all  deliverable  items. 

3.8. 1.6  geoortlnt.  The  contractor's  quality  assurance  organization  shall 
utilize  both  interdepartmental  and  lntradepartmental  reporting. chains  to 
assure  prompt  reporting  of  ehe  results  of  quality  assurance  activities. 

Quality  assurance  shall  follow-up  any  noted  discrepancy/action  assignment 
to  assure  timely  and  complete  correction  of  Che  problem. 


S.I.l.)  Authority.  When  conflict  exist.*  between  quality  assurance  and 
•Char  con tractor  functions  at  a  specific  task/eanagement  level,  Che 
coufllct  shall  be  resolved  successively  at  Che  next  higher  level. 

5.8.2  Program  design,  the  detailed  performance  requirements  for  the 
weapon  system  software  shall  be  audited  and  verified  as  being  able  to 
satisfy  the  requirements  of  operational  requirements,  operational  standards 
and  system  performance  specif leaeions,  as  any  be  provided  by  the  procuring 

agency. 

As  early  as  possible  la  the  design  phase,  t.ie  proposed  program  archi¬ 
tecture  shall  be  verified  as  to  its  capability  to  support  the  computa¬ 
tional  1  sad  Imposed  by  mseitmim  operation  of  all  functions  required  to  be 
slmultareously  serviced.  This  verification  may  require  extensive  modeling 
and  simulation  and  shall,  in  all  eases,  be  completed  prior  to  design 
implementation  and  coding. 

The  detailed  design  of  the  weapon  system  software  shall  be  verified 
against  the  performance  requirements  specified  by  the  procuring  agency. 

The  detailed  performance  requirements,  the  program  asehiteccure  and 
the  detailed  program  design  will  be  subject  to  review  by  the  procuring 
agency  at  scheduled  milestones  in  the  program  development  cycle.  Prior 
to  submission  of  the  detailed  design  to  the  procuring  agency  for  review, 
a  design  walk-through  shall  be  conducted.  This  design  wslk-through  shall 
be  accomplished  by  one  or  more  technically  qualified  persons  in  conjunction 
with  the  originator  or  originators  of  the  detailed  design. 

5.1.3  Frosrsm  production.  Programming  conventions,  program  design  rules 
end  programming  standards  shall  be  promulgated  to  and  followed  by  all 
levels  of  progrsm  production  personnel.  The  contractor  shall  insure  pro¬ 
grammers  are  skilled  in  ehe  use  of  the  specified  language  and  compiler 
capabilities.  Standard  procedures  shall  be  developed  for  pro graters  to 


follow  la  uso  of  coding  forms,  submission  of  coop 11 «  requests,  reports  of 
progress  end  associated  listings. 

A  code  walk-through  review  of  each  program  segment  shall  be  conducted 
prior  to  submission  of  the  program  for  compile.  This  review  shall  be  con¬ 
ducted  by  one  or  more  technically  qualified  persona  in  conjunction  with  the 
originator  of  the  code  being  reviewed.  Coding  shall  be  verified  for  com¬ 
plete  compliance  with  detailed  program  design.  Coding  shall  be  validated 
for  compliance  with  specified  programming  conventions  and  standards. 
Listings  for  developmental  segments  of  the  prograa  shall  be  thoroughly 
desk-checked  before  computer-run  testing. 

S.9  Program  test.  The  contractor  shall  determine  the  scope  of  tests  re¬ 
quired  to  ensure  that  the  program  being  developed  meets  all  specified  tech¬ 
nical  and  operational  performance  requirements  am.  the  acceptance  criteria. 
The  contractor  :hall  be  responsible  for  accomplishing  all  development  test¬ 
ing.  Test  plant. ing  shall  Include  development  of: 

a.  Progran  accaptanca  cr It aria.  * 

b.  Levels  of  tasting  to  vsrify  parforsancs. 

e.  Internal  procedures  for  scheduling  and  conducting  tests. 

d.  Detailed  procedures  for  testing  at  each  level. 

a.  Keportlng  procedures  of  tssc  results. 

All  teat  plans,  specifications  and  procedures  shall  be  subject  to  review 
sad  approval  by  the  procuring  agency.  The  procuring  agency  shall  ba  kept 
advised  of  all  teat  schedules  and  shall  ba  permitted  to  witness  all  tests 
with  designated  Government  or  contractor  representatives.  The  contractor 
shall  provide  all  supporting  software  necessary  to  conduct,  control  and 
record  easts.  The  contractor  shall  define  any  special  support  software 
necessary  to  satisfactorily  test  the  software  being  developed.  The  eon- 
traetor  shall  identify  to  eha  procuring  sgsney  any  GTT  or  CTI  required  to 
support  the  test  program  early  enough  to  allow  eha  procuring  agency  to 
obtain  and  deliver  any  such  requirements  without  Impacting  eha  development 
•ai  testing  schedule. 


ttM  contractor  shall  provide  or  Insure  tho  availability  of  adequate 
facilities  for  conducting  all  required  tests.  The  procuring  agency  shall 
have  the  option  of  specifying  the  facility  chat  should  be  used  to  conduce 
any  portion  of  the  east  program. 

Tho  contractor  shall  prepare  teat  reports  shoving  quantitative  results 
of  all  teats.  Such  reports  shall  be  signed  by  a  representative  of  the 
contractor.  Any  formal  or  informal  approval  of  the  eeseiag  results  by 
the  procuring  agency  representative  during  the  course  of  software  pro¬ 
duction  shall  not  be  construed  as  a  guarantee  of  the  acceptance  of  the 
finished  product.  Testing  shall  consist  of  the  following: 

a.  Subprogram/ module  testa 
h.  function  casts 
e.  System  performance  tests 
4.  Systems  integration  casts 

9.9.1  Suboroerae  module  tests.  Each  subprogram/modula  shall  be  subjected 

to  developmental  casting.  Such  casts  shall  ba  adaquaca  to  determine  compli¬ 
ance  with  the  eppllcable  technical,  operational,  and  performance  specifica¬ 
tions.  As  a  minimum,  each  sub program/ module  shall  pass  tha  following  tests: 

a.  Verification  of  the  coded  subprogran/aodule  to  ensure  that  it 
fully  satisfies  the  performance  and  daslgn  specification  require¬ 
ments  and  that  all  code  to  he  delivered  has  bsen  axarcisad. 
h.  Error- free  eonpile/esseably  of  the  coded  subprogrsa/module. 

«.  Exercise  of  the  sub program/ module  in  terms  of  iaput/output 

performance  with  the  results  satisfying  tha  applicable  performance 
end  design  specification  requirements. 

9.9.2  function  tests.  Subprogrsns/modules  shall  have  passed  the  subpro¬ 
gram/  nodule  tests  prior  to  being  subjected  to  functional  testing.  The  cub- 
progrsm/nodules  shell  be  integrated  Individually  into  particular  subsysten 
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programs.  Function  coses  shall  bo  sdequaea  Co  determine  comp 1 lane o  wleh 
the  applicable  technical,  oporaC tonal,  and  performance  specif icacions. 

3.9.3  Syscea  performance  coses.  All  subsyseen  programs  shall  have  passed 
Che  function  esses  prior  Co  system  performance  casting.  The  subsyscem 
programs  shall  be  ineegraeed  individually  uneil  all  subsyseem  programs 
have  been  ineegraeed  ineo  the  syseem  program.  These  tests  shall  be 

ad aquae a  eo  deeermiae  compliance  with  ehe  applicable  technical,  operational, 
and  performance  specif lcaeions.  As  a  minimum,  systems  performance  easting 
shall  be  performed  eo: 

a.  Verify'  Uje  total  man-machine  interface. 

h.  Validate  syseem  inleiaclon,  daea  entries  •'la  peripheral  devices, 
program  loading,  researeing,  and  ehe  monitoring  and  conerolling 
of  system  operacioa  from  display  consoles  and  ocher  concrol 
mentions  as  appllcabla. 

e.  Verify  tyseea  Incegraeion  of  equipmene  and  subsystems, 
d.  Verify  ehe  capability  of  the  system  eo  satisfy  all  applicable 
performance  and  systam  level  specification  requirements. 

0.  Via  the  dallbarses  insartlon  of  erroneous  inputs,  verify  ehe 

capability  of  ehe  syseem  eo  proparly  handle  and  survive  erroneous 
inputs  and  proper  Inputs  sneered  in  laproper  format  or  sequence. 

5.9.4  Systems  integration  ease.  In  instances  where  the  developed  pro¬ 
gram  is  a  component  of  a  larger  syscea  involving  ehe  ineegraeioa  of  two 

or  norm  programs  developed  as  separate  pro j aces,  the  individual  coneraceor 
.shall  be  required  eo  parelclpaea  in  eoeal  syscea  ineegraeioa  eeselng. 

Integra cion  teseihg  nay  be  conducted  ac  facilities  oeher  than  ehe  develop- 
■sac  facility,  such  as  s  Land-Based  Tesc  Site.  Each  coneraceor  shall 
provide  technical  support  eo  eha  integration  ease lag  as  required. 
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3.9.5  Software  trouble  reporting.  The  contractor  shall  develop  end  im¬ 
plement  internal  procedures  for  handling  end  reporting  all  software  or 
software  related  problems  identified.  In  addition  to  the  categories 
sad  priorities  described  below,  a  code  shall  be  utilized  to  Indicate  the 
status  of  each  Software  Trouble  Report  (STR)  as  it  progresses  through 
the  correction  cycle.  All  STRs  shall  be  verified  for  accuracy  and  cor¬ 
rectness  .vnd  submitted  on  standard  forma. 

The  contractor  shall  maintain  a  complete  sec  of  software  problem  data 
files  throughout  Che  duration  of  the  contract  and  make  this  information 
available  to  the  procuring  agency  or  his  authorized  representative  upon 
request. 


5.5.5.1  Software  trouble  report  cateeorv.  Software  problems  shall  be 
class if lid  by  category  as  follows: 

S.  brorram  trouble  (P).  The  program  ioes  not  operate  according  to 
supporting  documentation  and  the  documentation  is  correct. 

b.  Documentation  trouble  (D).  The  program  does  not  operate  according 
to  supporting  documentation  but  Che  program  operation  is  correct. 

C.  Design  trouble  (E).  The  program  operates  according  to  supporting 
documentation  but  a  design  deficiency  exists. 

4.  logic  trouble  (t).  The  program  has  a  logical  error  with  no  directly 
observable  operational  symptom  but  with  the  potential  of  creating 
trouble. 

3.3. 3. 2  Software  trouble  report  priority.  Software  problems  shall  be  classified 
by  priority  as  follows: 

a.  Motley  1  -  a  major  salfuncelos  rendering  the  entire  program 
or  a  major  functional  area  unusable  or  unreliable.  All  problems 
sf  s  asjor  nature  which  are  unpredictable,  that  is,  cannot  ba 
rsproduced  at  will,  shall  ba  dasslflsd  as  priority  1. 


b.  Priority  2  -  a  serious  malfunction  which  limits  ths  program  from 

performing  its  full  capability  and  for  which  there  is  no  alternative 
procedure  available. 

e.  Priority  3  -  a  malfunction  which  presents  an  erroneous  result  but 
for  which  the  program  provides  an  alternative  permitting  full 
capability  operation. 

4*  Priority  4  -  a  minor  error  or  operator  annoyance  which  has  no 
efface  on  the  operational  capability  of  the  system, 
a.  Priority  3  -  an  insignificant  error  or  no  error. 

5.10  Program  acceptance. 

BOTE:  This  section  is  presented  here  to  show  the  intended 
subject  matter.  The  content  of  section  5.10  will  be  modified, 
as  necissary,  to  be  in  conformance  with  ehe  final  version  of 
TADSTAMD  X  (Software  Quality  Assurance  Testing  Criteria). 
Incrementally  diring  development  and  prior  to  acceptance  by  the  procuring 
agency,  the  contractor  shall  demonstrate  the  complete  capabilities  of  the 
program.  This  demonstration  shall  take  the  form  of  meeting  the  incremental 
program  performance  criteria  by  formal  testing  and  auditing. 

Program  performance  criteria  shall  be  measured  by:  the  number  of  existing 
patch  words,  the  priority  and  number  of  outstanding  and  unresolved  Soft¬ 
ware  Trouble  Reports  (STRs),  the  endurance  run  time  without  system  failure, 
the  core  memory  requirements ,  and  the  timing  requirements  of  the  operating 
program.  These  criteria  shall  be  met  Incrementally,  during  development, 
prior  to  operational  employment  and  throughout  the  software  life  cycle. 

The  specific  criteria  and  their  relative  times  of  compliance  are  specified 
in  figure  3. 

These  performance  criteria  are  binding  on  all  software  program  types 
specified  in  this  standard. 
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a.  Formal  Qualification  Testing  (5QT)  shall  demonstrate  the  appli¬ 
cable  performance  requirements.  The  tesr  environment  shall  con¬ 
sist  of  actual  operational  and  interfacing  equipment  to  the 
extent  practicable.  Data  inputs  shall  be  operational  scenarios 
designed  to  demonstrate  the  correct  response  of  the  computer 
program  to  stimulation  actions  through  man-machine,  or  ocher 
external,  interfaces.  The  operating  procedures  for  the  program, 
as  detei mined  by  the  contractor,  shall  be  used  to  exercise  Che 
program  in  FQT. 

b.  Auditing  shall  verify  the  correspondence  end  correlation  between 
■all  deliverable  items  which  are  associated  with  and  support  each 

computer  program  entity  which  Che  contractor  has  been  tasked  to 
produce.  This  auditing  shall  include  but  is  not  limited  to  the 
following  items: 

(1)  Review  of  program  documentation  for  format,  completeness, 
correspondence  and  correlation. 

(2)  Review  program  listings  for  compliance  with  applicable  pro¬ 
gramming  standards  and  conventions. 

(3)  Verify  operator/user  manuals  as  complete  and  accurate. 

The  contractor  shall  prepare  all  materials  for  the  audit,  provide 
■space  for  tte  audit  group,  and  provldu  technical  asslacanu*.  The 
procuring  agency  or  designated  representative  will  direct  and 
eomerol  the  audit. 

3.11  Configuration  management.  The  contractor  shall  develop  and  implement 
procedures  to  ensure  the  positive  identification,  control,  status  accounting 
and  authentication  of  the  configuration  of  the  weapon  system  software,  the 
detailed  performance  requirements  and  the  detailed  program  design  during 
all  phases  of  the  development  effort.  The  contractor  shall  Insure  that 
such  procedures  are  integrated  with  the  configuration  management  procedures 
addressing  the  total  system  when  the  software  is  only  one  element  of  the 
weapon  system  being  developed.  Procedures  shall  provide: 
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•.  Positive  Identification  of  oil  program  elemencs. 
b.  lap id,  comprehensive  and  accurate  treatment  of  proposed  changes 
to  elements  under  configuration  control, 
e.  Comprehensive  implementation  of  approved  changes  and  dissemina¬ 
tion  of  corrected  documentation  and  program  changes, 
d.  Accurate  records  of  status  of  all  proposed  changes. 

«.  Verifications  of  change  control,  identification  and  status 
accounting  of  the  software  products. 

3.11.1  Conf iteration  identification. 

3.11.1.1  Baselines.  The  contractor  shall  establish  internal  baselines 
representing  the  approved  description  of  the  configuration  of  the  weapon 
system  software  under  development. 

3.11.1.2  Documentation  identification.  Thj  contractor  shall  establish 
titling,  labeling,  numbering  and  cataloging  procedures  for  all  descriptive 
documentation  and  program  material  which  sitisfy  the  following  criteria: 

a.  Denotes  the  program  to  which  it  applies 

b.  Describes  the  purpose  of  the  document 

C.  Defines  the  baseline  which  it  is  a  part  of,  or  in  support  of  * 

d.  Denotes  the  serial,  edition  and  change  status  of  the  document 

e 

The  dace  of  program  compilation  shall  be  indicated  as  part  of  the  identifier 
for  each  delivered  program.  Sequence  numbering  of  a  program  shall  be 
structured  so  future  changes  to  the  program  can  be  properly  noted. 

3.11.2  Configuration  control.  The  contractor  shall  establish  procedures 
for  the  formal  control  of  all  documents,  program  materials  and  the  develop¬ 
ment  support  library.  Procedures  shall  Include  the  establishment  and 
functioning  a  software  configuration  control  board,  the  methods  and  formats 

.  for  submission  and  acting  on  Software  Change  Proposals,  Software  enhancement 
Proposals,  Software  Trouble  Reports  and  Specification  Change  Notices. 


5. 11. 2.1  Software  configuration  control  boards  (SCC8).  Each  baseline  shall 
be  under  Chn  formal  control  of  a  responsible  board.  The  board  shall  identify 
end  maintain  the  complete  and  currenc  description  of  each  element  of  the 
baseline.  The  board  shall  consider  all  proposed  changes  to  the  baseline 

end  take  appropriate  action  on  each  proposal.  Each  proposal  shall  be 
analyzed  and  evaluated  in  the  following  areas: 

a.  Operational  Impact 

b.  Technical  d.eslgn  Impact 

e.  ke source  requirements  (e.g.,  cost,  personnel,  time) 

Tor  all  approval  changes,  the  board  shall  ensure  Implemented  changes  are 
reflected  In  all  baseline  documentation  under  the  control  of  the  procuring 
agency. 

Changes  which  r squire  the  approval  of  the  procuring  agency  shall  be  for¬ 
warded  by  the  contractor  with  complete  analysis,  evaluation,  and  recommen¬ 
dations. 

3.11. 2. 2  Software  changes.  NXL-STD-1679  shall  be  used  during  software 
development  to  communicate  changes  among  the  software  community.  Changes 
to  the  software  proposed  by  the  contractor  (Including  descriptive  documen¬ 
tation)  which  Is  under  configuration  control  by  the  contractor  or  Che 
government  or  both,  shall  be  submitted  to  Che  appropriate  software  con¬ 
figuration  control  board (s)  as  elthar  Software  Change  Proposals  (SC?) 

or  Software  Enhancement  Proposals  (SEP)  depending  on  the  classification 
of  the  changes.  An  SC?  or  SEP  which  has  cost  or  schedule  Impact  shall  be 
attached  to  e  fora  DD1692  (Engineering  Change  Proposal,  page  1)  completed 
and  numbered  In  accordance  with  reference  2.1. a. 

3.11.2.3  Documentation  chances.  Procedures  for  controlling  Che  preparation 
and  dissemination  of  changes  to  documentation  to  reflect  approved  and 
Implemented  SCPs,  SEPs,  and  STKs  shall  be  developed.  Such  procedures  shall 
be  designed  to  insure  the  simultaneous  promulgation  of  the  documentation 
sad  program  change. 


3. XI. 3  Configuration  seaeus  accounting.  The  contractor  shall  astabllsh 
procedures  eo  enable  the  generation  of  periodic  status  reports  on  all 
elesMnts  under  configuration  management .  Procedures  shell  ldeneify  ell 
SCPs»  SEPs,  and  STRs  in  preparation,  in  review,  end  In  the  current  stage 
of  Implementation.  Procedures  shall  identify  all  disapproved  end  deferred 
SCPs,  SEPs. ,  end  STRs. 

3.11.4  Configuration  authentication.  The  contractor  shall  utilise  con- 
flguratic l  authentication  techniques  which,  as  a  minimum.  Include  the 
following-. 

a.  k  review  process  thae  reconciles  deliverable  software  products 
to  their  approved  documentation. 

b.  Procedures  to  assure  thae  the  software  products  are  identified  as 
•rated  In  the  applicable  contract  requirements  and  the  approved 
project  configuration  management  plan. 

c.  Procedures  eo  be  used  by  the  change  control  authority  to  con¬ 
firm  Incorporation  of  ehe  approved  configuration  changes. 

d.  Procedures  for  ehe  reconciliation  of  configuration  status 
accounting  reports  and  status  (version)  of  the  software  pro¬ 
ducts  to  ehe  approved  baseline (s)  and  its  approved  changes. 

3.12  Management  conerol.  The  contractor  shall  determine  and  Implement  a 
management  system  for  ehe  development  effort  vhich  is  acceptable  to  the 
procuring  agency.  The  nanr.gememt  of  ehe  development  shall  emphasise 
efficiency  and  economy.  Clear  lines  of  authority  and  responsibility  shall 
he  established.  The  management  system  shell  provide  for  ehe  coordination 
•f  all  facets  of  the  development  under  a  master  schedule  of  events  and 
milestones.  Milestone  dates  shall  be  established  for  demonstrations  of 
evolving  software  capabilities.  Such  demonstrations  era  intended  eo  pro¬ 
vide  the  necessary  visibility  for  project  management  and  meaningful  out¬ 
put  for  produce  validation.  The  management  system  shall  provide  a  capability 


CO  monitor  the  progress  of  Che  development  by  mean*  of  regular  statu* 
reports,  reviews  and  audits.  The  management  system,  including  planning 
and  procedural  guidance  for  the  development  effore,  shall  be  compiled  in 
an  overall  plan  for  visibility,  formalization,  control,  and  coordination 
of  the  development. 

5.12.1  Organization.  The  contractor  may  use  an  internal  organization  of 
his  own  choice,  subject  only  to  the  requirements  from  this  standard 
which  are  invoked  by  the  procuring  agency.  The  contractor  shall  designate 
an  overall  manager  for  Che  development  effort.  Th  >  functions  of  design, 
production  and  test  shall  be  given  organizational  'risibility.  The  relation- 
Ship  of  all  support  functions,  both  full-time  and  part-time,  required  to 
support  the  development  effort  shall  be  clearly  defined.  The  responsi¬ 
bilities  of  all  sub-contractors,  if  used,  shall  be  clearly  visible  to  the 
procuring  agency. 

5.12.2  Resource  management.  The  contractor  shall  determine  his  resource 
requirements  in  the  three  areas  of  personnel,  facilities,  and  equipment. 
Planning  shall  be  completed  early  enough  to  permit  orderly  acquisition. 
Installation  and  training  (if  applicable),  of  resources  on  an  optimum 
schedule  to  prevent  delay  and  to  avoid  dead-time.  Planning  shall  be 
responsive  to  schedule  changes.  The  cuneractor  shall  avoid  sharp  fluc¬ 
tuations  in  personnel  requirements  by  judicious  shifting  of  personnel  as 
development  tasks  change. 

Reusability,  permanency  or  length  of  project  and  convenience  of  location 
shall  be  weighed.  The  procuring  agency  nay  direct  Che  use  of  government 
or  ocher  facilities. 

The  contractor  shall  consider  ehe  cost-effectiveness  of  commercial  equip¬ 
ment  to  assist  in  the  development  where  appropriate.  Where  weapon  system 
equipment  la  Government- furnished  or  Government-specified,  the  contractor 
shall  be  responsible  only  for  the  cost-effectiveness  of  its  use  and 
maintenance,  not  its  acquisition.  The  possibility  of  continuing  use  of 


Che  equipment  by  the  Government  during  the  operational  support  phaaa  of 
tha  sofewart  lift-cycle  shall  bo  a  consldsraclon.  Tho  contractor  shall 
Implement  a  system  of  management  aonitorlng  of  utilization  In  tho  aroas 
of  personnel,  facllitiso,  and  equipment  considering  both  quantity  and  cost. 
Actual  utilization  races  shall  be  compared  to  predicted  rates  at  least 
monthly.  The  procuring  agency  aay  specify  more  frequent  comparison. 
Variations  shall  be  expeditiously  Investigated  and  corrective  action 
initiated.  Personnel  stability  and  productivity  shall  be  measured 
regularly. 

3.12.3  Status  reviews.  Status  reviews  nay  be  requested  by  the  procuring 
agency  at  regular  Intervals  during  the  development  effort.  The  contractor 
shall  be  able  to  provide  information  at  these  reviews  to  apprise  the 
procuring  agency  of  current  status,  progress,  problems,  and  critical  Items 
occurring  in  the  development  effort  within  the  purview  of  the  contractor. 

3.12.3.1  Status  review  subjects.  The  contractor  shall  address  the  following 
subjects,  as  appropriate  to  the  stage  of  the  development  effort,  in  each 
Status  review: 

a.  Organizational  changes,  managerial  personnel  changes 

b.  Program  design  status 

c.  Development  schedule  status  (milestone  prognosis) 

4.  Coding  status 

a.  Software  Trouble  Report  (STR)  status 

f.  Software  Change  Proposal  (SCP)  status 

g.  Software  Enhancement  Proposal  (SEP)  status 

h.  Integration  schedule  status 

I.  Testing  status 

J.  Deliverables 

fc.  Progress  on  previous  problems 
1.  Dew  action  ltems/problems  , 


a.  Delinquencies:  governmental ,  outside  contractor,  subcontractor, 
and  latamal 

a.  Manpower  utilization 

«.  Facilities  utilization 

p.  Coaputar  system  resource  utilization  (see  S.S.2) 

q.  Financial  summary 

3.12.3.2  Status  review  subject  items.  Within  eac.n  subject  area  ,  the  con¬ 
tractor  shall  cover  the  following  items,  as  applicable: 

a.  The  program  schedule  updated  to  the  end  of  this  reporting  period. 
.  b.  Major  difficulties  encountered  and  plans  to  overcome  them. 

Including:  Tasks /units  that  are  currently  behind  schedule  (or 
have  anticipated  schedule  changes),  their  effects  on  completion 
of  the  project,  and  steps  being  taken  to  remedy  schedule  delays. 

a.  Other  information  which  defines  cause  and  effect  of  significant 
changes  on  the  contrset  schedule. 

d.  Problems  which  actually  or  potentially  will  causa  deviation  from 
contractual  requlremants. 

a.  Summary  of  mootings  and  eonfarancaa  hold  during  tha  r sporting 
period  including  action  items  with  dua  dates  for  both  tha  con¬ 
tractor  and  tha  procuring  agency.  Current  statua  of  action  items 
shall  ha  Included  until  reported  closed. 

3.12. 3. 3  Documentation  reviews.  Documents  and  programing  materials  as 
specif led,  shall  ba  scheduled  for  detailed  review  prior  to  approval  or 
acceptance.  The  purpose  of  the  review  shall  bt  to: 

a»  Verify  that  tha  subject  documents  and  programing  materials 

comply  completely  and  seeurataly  with  the  performance  require¬ 
ments  or  design  specifications  of  the  previous  documents  and 
programing  materials  and  all  other  standards  and  constraints 
imposed  by  tha  procuring  agency. 


fe.  Validate  the  accuracy  and  completeness  of  cho  documents  and 
pro  trimming  aatariala  by  checking  for  all  components,  their 
correct  cross-reference  and  editorial  accuracy. 

Tho  reviews  shall  be  in  two  stages;  a  preliminary  working-level  review, 
followed  by  a  formal  (or  critical)  review  after  changes  resulting  from 
Cbm  preliminary  review  have  been  entered.  Reviews  shall  be  scheduled  by 
Cho  contractor,  with  the  concurrence  of  the  procuring  agency,  and  in 
accordance  with  milestones  in  the  software  development  plan.  The  procuring 
agency  any  designate  other  activities  to  participate  in  the  review.  The 
contractor  shall  distribute  drafts  of  review  documents  and  programming 
material:!  to  each  designated  activity  sufficiently  in  advance  of  the 
scheduled  preliminary  review  to  allow  adequate  internal  review  by  each 
actlvlcy.  The  contractor  shall  distribute  a  corrected  version  of  the 
review  documents  and  programming  materials  after  completion  of  the  pre¬ 
liminary  review.  The  critical  review  for  the  acceptance  or  approval  of 
the  doeuuants  and  progressing  materials  shall  expeditiously  follow  the 
distribution  of  the  corrected  version. 


5.12.3.4  Special  reviews.  Special  reviews  may  be  scheduled  by  the  pro¬ 
curing  agency  at  major  milestones  or  events  in  the  development  effort 
mat  covered  by  Baseline  Ievlevs  or  Status  Ievleva.  4  special  review  of 
the  tost  program  as  developed  shall  be  conducted.  The  contractor  shall 
furnish  the  same  support  for  special  reviews  as  for  bssallne  reviews. 

5.12.4  Inspections  and  audits.  The  procuring  ageney  nay  employ  a  physical 
inspection  to  determine  cho  contractor's  eonformaca  with  contractual 
requirements.  As  a  minimum,  areas  of  incarssc  include  development  facilities, 

■  documentation  controls,  deliverable  data  items,  Government-Imposed  staa- 
s  dards,  and  contractor  internal  standards. 
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a.  facilities.  The  development  and  cut  facilities  say  b«  Inspected 
for  eooesaeeual  conformity  at  any  elms  during  the  life  of  a 
sofevare  system  development  contract. 

b.  Configuration  management.  Contractor  conformance  with  the 
approved  Configuration  Management  Plan  may  be  audited  through 
examination  of  records  and  attendance  at  change  control  Board 
Matings. 

e.  Internal  standards.  The  procuring  agency  may  audit  the  con¬ 
tractor's  conformance  with  internal  standards  of  software  develop¬ 
ment  <tnd  conerol. 

4.  Quall.rr  assurance.  The  procuring  agency  oay  audit  and  inspect  the 
contractor's  conformance  with  the  appro-red  Software  Quality 
Assurance  Plan. 
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APPENDIX  B  -•MILITARY  STANDARD  490 


«ai  section  I,  Scan-  The  content  of  Section  t  k  hand*  a  general  description  of  the  pcnph- 

tt  a  computer  program  development  yetificatiou  anl  equipment  with  which  iha  quaffed  program  will 
M^aa  defined  in  the  following  example:  ferirfira 


i.  scon-: 


ft  hadda  a  paml  deicriptioar  of  any 
i  ailk  which  iha  rpecifiad  program  wdl  u 


1.1  IdamjflcaliM.  Thu  paragraph  dial  eoatahi 
Iha  approve  I  identification,  aomrodaiiiit.  and 
anthoriaed  abb  aviation  for  iha  computer  program. 

U  Fomdawd  aaaaaaary.  Thii  parapaph  dull 
domain  a  briaf  deacriptioa  of  iha  overall  computer 
program  bp  nujor  functkMa  (taaka).  It  dull  further 
IdruJfy  and  aummariaa  the  apacdication  coolant, 
anmpudliun.aid  intent. 

ML2  Sactfos  2.  Applicable  docnu.nW.  The  com 
Ml  of  thia  Section  2  dull  be  in  accordance  with  42. 

WJ  Sacdoa  3,  laprioneaft  Thia  ia  the  major 
aaction  of  the  computer  program  development  rped- 
Acaiion.  It  dull  consist  of  a  achat  of  parapaphi  that 
apadfy  in  detail  the  performance  requirements  of  the 
•amputee  program.  Thia  aaction  duM  define  and 
apaedy  al  functional  performance  requirement*.  it- 
ipi  constraints.  and  aundarda  necaaaary  to  enure 
proper  development  of  the  computer  program.  Thia 
potpapk  dull  eoauin  a  brief  general  drirmaion  of 
<>•  overaB  ayrtem  within  which  the  program  wtil 
operate.  It  dull  dww  the  eriauondupe  of  each  sob- 
trim  with  the  computer  program  portion  of  the 
prism  In  pedicular,  the  rale  aadgned  to  the  coot- 
paler  program  dtoold  be  acnared  to  ddmrate  the 
Imadona  it  mmt  arcompliih  far  the  ryatam  As  the 


ft  Florida  a  brief  general  dferiHriao  of  du 
aootrii  gmm  aod  ouha  rafaranca  to  other  ayftam  m 
ftthayrtem  perfomunce  rpedficatiom  that  wH 


d  Florida  a  general  dttcription  of  the  mger 
ftuctiona  of  the  computer  program  relative  to  the 
manner  in  which  they  will  be  uibeequendy  treated. 

dOJ.I  fompupA  il.  Program  dr/Wdma  Thia 
paragraph  dull  provide  a  detailed  dsscnpboo  of  du 
major  function*  of  du  computer  propam.  Thia 
paratpaph  dug: 

ft  !3d*a  the  requirements  imposed  am  the 
computet  propem  by  each  interfacing  equipment  and 
*ail  include  putpoee  of  equipment,  computer  inter- 
te  description,  equipment  option*  and  controls.  and 
tinting  and  accuracy  liaulaiionr. 

k  Provide  timing  and  mquennng  interface  re- 
Vinmtntt  bapoted  by  other  computer  progranu  or 
by  aquipmint  or  operational  limitatinna 

ft  Oaacribe  the  major  function*  of  the  com¬ 
puter  propam  Including  their  interaction,  rrquendng 
and  timing  requirtmenu.  Block  diapams  of  the  mier- 
(eon  dull  be  provided  to  facilitate  pmaeaiatioa  of 


tkJ.2  fwntgmpk  22,  Ormdrrf/lMcrimiafmfidro- 
mnaa  Ike  whperagnph*  under  thia  panpapb  dud 
aoataia  the  neceaury  detailed  test  end  mathematical 
dtieriplioar  far  each  of  the  rrquartd  computer  pro- 
gram  Auctions.  A  aal  of  rubparapaphs  dial  ha 
pnparod  for  each  major  Auction  or  mbftinction, 
•Afchmt  ia  required  for  darity.  Descriptive  md 
Introductory  malarial  for  each  fuacrioo  duM  be  he- 


fiUI  fhmpqph  it2f.  fopum  Thia  paragraph 
Ml  provide  a  detailed  deacriptioa  of  al  input  data. 
Smrca  of  the  input,  method  of  Inmiriou.  and  mlidily 
thacka  riul  ha  defined.  Qumtiry  and  timing  of  the 


t*  ' 


hqmt  <iti  and  Marcia  ted  limits  ihsD  be  specified. 
Operator  coo  (tot  requirements  shall  be  deuiied.  m- 
Cbeding  names  and  descriptions  of  operator  actions. 
Wastes  or  operator  positions  where  applicable,  and 
As  esquired  programmed  restrictions. 

Mill  Paragraph  3.22  Protesting.  This  para- 
pub  shall  provide  a  textual  and  mathematical  de¬ 
scription  of  each  of  the  processing  requirements  of 
each  faoction.  Presentation  of  (he  mathematical 
damripbons  under  each  function  shall  include: 

a  Purpose  -  This  area  shall  describe  the  exact 
hlant  of  the  ma the.ru tscal  operationft).  This  involves 
a  definition  of  the  specific  input  and  output  param- 
aisri  and  the  ptoca  ring  required 

h  Approach  -This ana  dull  contain  a  textual 
dwolption  of  each  mathematical  operation  specified 
The  accompanying  narrative  shall  identify  accuracies 
inquired,  sequence  and  timing  of  events,  and  relevant 
restrictions  or  limiiations.  Derived  equations  shall  ha 
damns  with  appropriate  mathematical  and  eontral 
qnnbob  adequately  defined. 


e  flhpmi  jf  Geometry  -  Suitable  diagnma 
M  be  included  in  the  text  produced  under  the 
gmoediiigpeiagrapuc  where  eppheabie. 

MIU  Pmgntph  3.23.  Outputs.  This  paragraph 
duH  provide  a  detailed  description  of  aO  output  data, 
aontrol  parameters,  and  displays.  Method  and  timing 
af  outputs  shall  ha  described  comptcuiy.  Operator 
output  requirements  (e  g,  hard  copy,  CRT  displays) 
■■al  include  name,  content,  taming,  format  and 
meting  of  the  Information. 


«U4 


k  124.  Sped*  requhemerta. 
dttaiM  ducriptiow  of 


IX  Adaptation  Them  pan- 
a  description  of  (he  data  reqoire- 


pre scribed  limits.  Them  data  an  divided  into  three 
dimes  and  presented  m  follows. 

MJ.3.1  Paragraph  33.1.  General  environment. 
This  paragraph  shall  contain  a  description  of  environ- 
msatai  data  detailing  the  characteristics  anticipated 
for  all  particular  installation  l  Each  installation  wig 
select  end  set  the  required  data  end  value  for  opera¬ 
tional  urn.  Examples  of  such  data  art:  grid  limits, 
radar  ranges  and  areas  of  coverage,  prescribed  safety 
limits,  etc. 

MU.1  Paragraph  332.  System  parameters.  This 
paragraph  Ml  contain  a  description  of  constants  re¬ 
quited  by  one  or  more  subprograms  that  may  change 
from  time  to  time  incrementally  within  a  specified 
nogs  according  to  operational  needs.  Such  data  cow¬ 
ries*  of  afiowable  trajectory  deviations,  missile  per- 
fosmanee  characteristics,  etc. 

M3JJ  Paragraph  3.3.3.  System  edacities.  This 
paragraph  dull  contain  a  description  of  the  capacity 
requirements  for  the  computer  program.  Items  such 
as  compatibility  for  total  simultaneous  target  hand¬ 
ing,  total  number  of  Simultaneous  missile  trajectory 
controls,  total  number  of  simultaneous  displays  and 
operator  station  requests,  etc.,  shall  be  described.  The 
system  capacities  are  directly  related  to  computer 
SHsagi  capacities,  interfacing  subsystem  timing  rates, 
and  interfacing  equipment  capacities. 


fO.4  Section  4,  Qualify  assurance  provisions.  This 
section  shall  specify  test/verification  requirements, 
methods  of  verification,  and  the  necessary  test  tool* 
and  facilities  to  conduct  the  required  tests/verifica- 
ttons.  This  section  shall  establish  the  require  menu  foe 
As  test  plans  and  procedures  that  must  be  formu¬ 
lated  for  verification  of  the  program.  The  intent  of 
Urn  test  effort  it  to  verify  that  the  performance  re- 
quhtments  m  stated  in  Section  3,  of  the  specification 
have  been  met.  The  following  paragraphs  shall  be 


MAI  Paragraph  4.1.  Introduction  This  para¬ 
graph  ring  establish  the  requirement  for  development 
of  a  last  plan  and  tern  procedures  for  the  subject 
program.  It  shall  specify  Urn  following  levels  of  tatt- 

«*r 


system  sopacitiei  Adaptation  data  is 
m  bt  centrally  modified  at  needed  so 
m  of  Bpersiionai  functions  within 


11? 


C  Computer  program  acctptanca  tatting 
4  Sytttm  integration  testing 

ML4.3  Paragraph  4.2.  Test  requirement*  This 
pHagraph  dull  specify  the  requirement*  for  each 
M  of  testing  except  the  acceptance  teat  level.  For 
each  level,  the  test  tools  and  facilities  requited  shall 
he  verified.  The  requirements  shall  include  test 
fat  mules.  algorithms,  techniques  and  acceptable  tol¬ 
erance  limits,  as  applicable. 

M.43  Paragraph  4.3.  Acceptance  tut  requin- 
metro.  This  paragraph  shall  establish  the  means  by 
which  the  procuring  agency  may  formally  accept  the 
wsnspuiet  program  at  fulfilling  the  performance  re- 


HffTB:  Sfeee  the  depth  of  cotungepomiMe  in 
fide  section  depends  upon  the  type  of  program  to  be 
Hated,  the  minor  um  essential  content  of  this  section 
dMI  include  the  establishment  of  the  lew  is  of  tests 
seqnirsd  and  the  requirement  for  production  of  test 
flan  snd  lest  procedures  documents. 


the  contractual  sense,  eg.  it  shall  not  include  require¬ 
ments  that  constrain  design  or  development,  or  qual- 
ify  dm  performance  requirements.  This  section  shall 
include  a  Irat  of  aU  documents,  specification!,  etc, 
that  an  necessary  for  program  development  and  that 
are  not  included  with  this  specification. 

Ml 7  Section  10.  Appendbt  I.  This  section  of  the 
Verification  shall  contain  requirements  which  an 
contractually  a  part  of  the  specification  but  which, 
in  convenience  in  specification  maintenance,  re  in¬ 
corporated  terein.  e.g.,  requirements  of  a  temporary 
nature  or  let  limited  effectivity.  Appendixes  may  be 
bound  as  -epante  documents  for  convenience  in 
handling.  e.g.,  when  only  a  few  parameters  of  the 
program  me  classified,  an  appendix  conuining  only 
tfm  rfmwfiif  material  may  be  esublishcd.  Where 
pnransettrs  ate  placed  in  an  appendix,  the  paragraph 
of  Section  *0  shall  be  referenced  in  the  main  body  of 
the  progwi  specification  in  the  place  where  the 
parameter  would  normally  have  been  specified. 
Typical  dr-a  that  may  be  included  in  computer 
program  development  specification  appendixes 


MLS  Section  S,  Preparation  foe  delivery.  This  tac¬ 


tion  is  normally  not’appiicabie. 


A  Matnemetical  derivations 
k  Alternate  method 


tiM  faction  t.  Notes.  This  section  shall  indude 
Hibernation  that  is  stated  for  administrative  con- 
rowtano*  only,  end  it  not  a  part  of  the  specification  in 


c  Summary  of  equations 
4  Definitions  of  terras 
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